システム開発における情報セキュリティ12

　この記事は、システム開発における情報セキュリティ11の続きです。前回は、人とセキュリティの関係について解説しました。今回は、セキュリティに関するルール作りについて解説します。
　前回「関係者全員に細かいルールや複雑な手順を強いるのもまた間違い」だと明言しました。では、具体的にどうすればよいのでしょうか？今回はその件について書きます。
　真面目にセキュリティ対策を考えるのであれば、守られなくなるのが目に見えている細かいルールを定めてはなりません。細かいルールを作っていると、それだけでセキュリティ対策をやっていると錯覚しがちですが、実際には役立つどころかセキュリティの効果と業務効率を下げる元凶になります。
　細かいルールを作る方針では、日々進化するクラッキングテクニックに対抗するために自然とルール数が増加し、直ぐに人間が覚えられない量になります。人間が覚えられないセキュリティ対策ほど効果がないものはありません。それどころか、セキュリティ対策そのものが軽視され、非常に危険な状態になる可能性すらあります。従って、無闇に細かなルールの数を増やすのではなく、セキュリティの本質を押えたセキュリティポリシーを定めるべきです。
　セキュリティポリシーについて書くと長くなるので次回に続きます。

システム開発における情報セキュリティ11

　この記事は、システム開発における情報セキュリティ10の続きです。前回は、人災および災害に関するセキュリティ対策を解説しました。今回は、人とセキュリティの関係について解説します。
　システム開発に従事している人達はセキュリティについて、どうしても技術よりの見方をしてしまいますが、セキュリティ対策は人の行動が大きな比重を占めています。セキュリティ対策は、セキュリティに関係する機能を実装するだけでは不十分であり、運用マニュアルの整備およびセキュリティ意識の向上がともなければ意味をなしません。
　セキュリティは情報資産をどのように取り扱うのかを考え、その考えと方針を徹底的に関係者に伝えてこそ効果を発揮します。関係者に対して徹底したセキュリティ意識を持たせるというと、日本の会社は正社員だけを考えがちです。また、警備員、清掃員といった外部の人員も見落としがちです。しかしながら、情報資源はあらゆる経路で漏えいします。セキュリティは一つの弱点が全てを駄目にしてしまうのです。
　ただし、セキュリティを徹底的に実施すると言っても、関係者全員に細かいルールや複雑な手順を強いるのもまた間違いです。人は余りにも細かいルールや、多すぎるルールには従えません。本人にやる気があっても、ルールが多すぎればどうしても抜けが生じます。また、普通の人はたいした悪意もなく、細かすぎて業務を妨害するルールを破ります。
　セキュリティが難しいのはこういった事が原因です。セキュリティ対策は「やらなくては駄目」、「やり過ぎても駄目」、「穴があっても駄目」という非常に難しいものです。セキュリティ対策は基本的に量よりも質です。ただ実施するのではなく、質が高い少数のセキュリティ対策を行います。
　勘違いがないように明記しておきますが、少数とは言ってもそれは人から見ての量です。システムを構築する側は、非常に膨大な量の対策をしなくてはなりません。その辺を勘違いしないように注意して下さい。
　

システム開発における情報セキュリティ10

　この記事は、システム開発における情報セキュリティ9の続きです。前回は、認証とセキュリティについて解説しました。今回は、人災および災害に関するセキュリティ対策を解説します。
　セキュリティ再策で忘れがちなのが、クラッカー（悪意を持った犯罪者）以外にも情報資源を破壊するものが存在するという事実です。人間は間違える存在です。誤ってデータを入力したり、誤ってデータを消してしまったりします。また、地震・津波・落雷・水没などの災害も起こります。それらの災害から情報資源を守るのもセキュリティ対策です。
　情報システムは人間が間違えることを前提とし、幾重にも防御をしなくてはなりません。例えば、誤っているデータは登録できないようにし、それでも誤りが生じる恐れがあるので、点検するための機能を用意しなくてはなりません。ポイントは人とシステムの連携です。
　コンピューターは人間の気持ちを理解できません。それに加えて、論理的な過ちも検出できません。出来るのは機械的なチェックだけです。それらの機械が検出できない過ちをチェック出来るのは人間です。そういった人の仕事も加味してシステムを構築します。
　次に自然災害に関するセキュリティ対策を述べます。自然災害は避けようがありません。従って、情報資源の消失とシステムダウンを前提とした対策法を考えます。具体的には、情報資源のバックアップ、情報資源の物理的分散化、停電対策、機械の破損対策、連絡体制の整備・・・などを決定し、それが何時でも実施できるように定期的な訓練をします。
　ここで重要なのは「想定外を想定する」という事です。日本では絶対に安全だと信じ切ってしまう風潮があります。なおかつ、「不吉な事を口にするな」と怒鳴り、災害を考える事すら避ける傾向もあります。しかしながら、物事に絶対は存在しません。最悪の場合どうするのかを考えなくてはセキュリティ対策とは呼べません。システムは常に最悪を想定しなくてはならないのです。想定外という言葉は技術者が口にする言葉ではありません。
　人災と災害については奥が深いテーマですが、長くなるので今回は終わります。

システム開発における情報セキュリティ9

　この記事は、システム開発における情報セキュリティ8の続きです。前回は、情報資産のアクセス方法とセキュリティについて解説しました。今回は認証とセキュリティについて解説します。
　アクセス方法を定めた後は、認証について考える必要があります。情報資産は適切な人物以外に、不適切な操作させてはなりません。例えば、不適切な人物に顧客情報を見せるのは危険ですし、不適切な人物が重要な情報資源を改善したら大変な事になります。そうした事から、情報資源を操作する人物を認証するシステムをよく考えなくてはならないのです。
　システムをクラッキングする方法は星の数ほどありますが、その中で大きな比重を占めているのが、権限がある人物になります行為です。情報システムに侵入する事に成功したクラッカーやウイルスは、権限を昇格するのが基本です。権限の昇格とは、システムの不備をついて、自信が持つ権限を強くする行為の事を指しています。また、ソーシャルエンジニアリングの技法を使い、より強い権限を取得する行為もあり得ます。
　こうしたクラッキングの脅威に対処するためには、認証システムを情報技術と組織体制の両方の観点から考えます。情報技術側の対処としては、パスワードが基本ですが、アイリスや指紋などを使った生体認証もあります。組織的対策は、電話の主や訪問者をよく確かめる手順の決定と訓練をするのが基本です。
　この様に色々な対策方法があり、基本的な物でもそれなりの効果があるのですが、基本とはいえ実施は大変です。具体的には、パスワードの管理方法をどうするのか、パスワードを変更はどうするのか、掃除婦やアルバイトの人まで訓練するにはどうすればいいのか・・・など色々な課題が生じます。
　しかしながら、現代は情報資源が重視される時代ですので、認証方法を考えなくてはなりません。認証方法をおろそかにすると、他のセキュリティ対策を実施しても無駄になってしまいます。大変ですが避けては通れないのです。

システム開発における情報セキュリティ8

　この記事は、システム開発における情報セキュリティ7の続きです。前回は、情報資産の位置とセキュリティについて解説しました。今回は、情報資産のアクセス方法とセキュリティについて解説します。
　情報資産の位置が決まったら後は、その位置にある情報資産にどうやってアクセスするのかを考えます。位置を考慮しアクセス方法を大別すると、グローバルとローカルに分けられます。さらにローカルを分類すると、個人のPCとローカルエリアネットに分けられます。
　個人のPCなどに保存される情報資産は、一時的なものか個人的なものです。そういった情報資産については、適切な人だけをアクセスする方法と、紛失時の対応について考える必要があります。
　例えば、業務で作成した一時的な情報資産を保存したノート型PCを紛失した場合、そのノート型PCを拾った人がその情報資産を取得する事が可能となってしまいます。また、席を離れた隙に他人がそのPCを使用する可能性もあります。そういった可能性を考え、個人認証システムと情報資産の暗号化を検討します。それに加え、「作業が終わったら一時情報を必ず消す」、「個人情報は保存しない」などの業務規則も必要となります。
　ローカルエリアネットワークに保存されている情報資産は、業務上の機密情報が多いため、個人的な情報よりも慎重にアクセス方法と運用管理方法について考えなくてはなりません。基本的に権限がない人は全て拒否する方針で考えます。また、物理的なセキュリティも考えなくてはなりません。物理的なセキュリティとは、サーバーが置いてある部屋への入室を制限する、業務が停止している間はデータベースサーバーの電源を入れないなどといった事を指します。そういった物理面のセキュリティは忘れやすいので注意しましょう。
　最後にグローバルな情報資源について書きます。グローバルな情報資源は非常に危険だと考えて下さい。クラッキング方法はいくらでもありますので、ローカルな情報資源よりも細かい単位で、アクセス方法とセキュリティについてを考えなくてはなりません。具体的には、使用するプロトコル、業務規則、管理方法、運営方法を細かく分析します。
　TCP/IPはセキュリティ意識が低い時に設計されたものであり、プロトコルそのものに弱点が存在します。そういった根本的な弱点がありますので、プロトコルの仕様を踏まえてセキュリティ対策を考えなくてはならないのです。システムを設計する人は、クラッカーになったつもりで不正にアクセスする手段を考え、その不正アクセス方法を防ぐ方法を検討します。
　しかし、技術だけを考えてセキュリティ対策をしても不十分です。ソーシャルエンジニアリングによるクラッキングが考えられますので、プロトコルといった情報技術だけではなく、情報資源を扱う人間を対象にしたセキュリティも考えなくてはなりません。ですから、業務規則、管理方法、運用方式まで詳細に分析し、クラッカーがどのように不正アクセスするのかを考え、それを元にセキュリティ対策の実施／実現方法を考えます。続く...

システム開発における情報セキュリティ7

　この記事は、システム開発における情報セキュリティ6の続きです。前回は、権限の取り扱いについて解説しました。今回は、システム設計時に考える事柄について解説します。
　システムが取り扱う情報資源と、情報資源に対する権限について考えました。次に考えるべき事は情報資源の保管場所です。何故ならば、セキュリティ対策は情報資源の保管場所によって変わるからです。
　データベースサーバーに保存する場合と、ファイルに保存する場合のセキュリティ対策は違います。また、ローカルネットワークで情報資源を共有する場合と、遠隔地にあるネットワークにある情報資源を使用する場合では、セキュリティ対策が異なります。従って、情報資源の保管場所はセキュリティに於いて大変重要です。
　なお、情報資源をどこに置くのかは、情報資源の性質によります。複数の人が必要とする情報資源ならば、遠隔地からアクセスできるようにせねばなりません。一方、ごく一部の人間しか使用しない機密情報はローカルに管理し、遠隔地からアクセス出来ないようにする必要があります。
　すなわち、情報資源は適切な場所に配置する必要があるのです。情報資源は適切な場所に配置しましょう。

システム開発における情報セキュリティ6

　この記事はシステム開発における情報セキュリティ5の続きです。前回は、役割と権限の識別を解説しました。今回は、権限の取り扱いについて解説します。
　権限の識別が終わったら、権限のCRUD（生成・参照・更新・削除）と人が持つ権限のCRUDについて考える必要があります。新しい仕事が出来れば権限は生成されますし、ビジネスプロセスの見直しにより不必要になる権限もあります。また、昇進した人には新しい権限を与えられ、退社や不祥事などの事柄で権限は剥奪されます。そういった人員に関するイベントで権限に関する情報は常に変動します。それら権限のライフサイクルと利用状況を、どのように取り扱うのか事前に考えてなくてはならないのです。
　何故ならば、開発者の視点でセキュリティを考えていると、システム内のセキュリティに目が向き、システムを利用する外部システムである組織レベルのセキュリティが疎かになるからです。情報社会を迎えた今、システムは組織に密着するものであり、組織とは無関係でいられません。
　システムを構築する際は組織レベルで物事を考える必要があります。現実（組織／業務）と理論（システム）の乖離がセキュリティの虚弱性を生みます。隙を生みださないために広く深く考え抜きましょう。

システム開発における情報セキュリティ5

　この記事はシステム開発における情報セキュリティ4の続きです。前回は、見つけ出した情報資産についての分析を解説しました。今回は、役割と権限の識別を解説します。
　システムを導入する組織には、様々な役割の人がいます。それらの人々は日常の業務で業務をこなすために、様々な情報にアクセスし、求められる情報を生みだします。ここで考えなくてはならないのは、業務を行う上で必要な情報と適切な権限です。もし、あらゆる情報がアクセスできる権限を与えれば、情報漏洩の危険やシステムダウンの可能性が高くなります。また、何か問題があった時に、犯人を突き止めなくてはなりません。適切な役割に、適切な権限を与える事を考えなくてはならないのです。
　情報セキュリティの基礎的な考え方は、「最小限の権限だけを与える」です。権限を考える際には、業務に最低限必要な情報にアクセスできるようにするのが原則です。従って、分析をする際に「どの役割の人がどの情報を必要とするのか」を分析する必要があります。
　それに加えて、組織間もしくは部署間でやり取りする情報にも注目せねばなりません。業務では複数のグループが必要とする情報もあります。例えば、生産管理をするグループは、需要予測を立てる為に販売データが必要になるでしょうし、連結決算時には子会社や関連会社の財務データが必要となります。個人単位もしくは単一の役割単位で権限を考えると、思わぬ落とし穴が出来てしまうので注意しましょう。
　そういった事から、システム開発に於いて、役割と権限を洗い出す作業は非常に大切です。この作業は、どこか特定の工程だけですればよいというものではありません。全工程にまたがり、情報が判明するたびに権限をチェックせねばなりません。非常に地味で退屈な作業ですが、セキュリティを高める上で欠かせない作業です。面倒くさがらずにしっかりと行いましょう。

システム開発における情報セキュリティ4

　この記事はシステム開発における情報セキュリティ3の続きです。前回は、システム開発で最初にするべき情報セキュリティの取り組みについて解説しました。今回は、見つけ出した情報資産についての分析を解説します。
　情報資産を見つけた後、するべき事があります。それは、情報資産の価値を算定する事です。情報セキュリティは、全ての情報資産を無目的に保護する概念ではありません。情報の価値に見合った適切な対応をするのが情報セキュリティです。
　とはいえ、情報資産の価値を算定すると言われてもピンとこない人が大半でしょう。全てを語るときりがありませんので、開発者が知るべき事柄を噛み砕いて解説します。
　先ず、情報が持つ価値とは何かについて考えます。開発者は全てが等しく思えるかもしれませんが、企業から見れば情報にも価値の高低があります。
　例えば、お客様についての情報は、有効に使えば多大な利益をもたらします。また、漏れれば法的および倫理的な問題が生じ、企業に多大な損害を与えます。一方、自社が販売している商品の名前は広く知られないと困ります。ですが、自社が全力で資財を投入している重要な商品についての技術情報が漏れれば大変困ります。
　これらの例から分かるように、情報資産には経済的な価値があります。しかしながら、全ての情報を完璧に保護するのは人間には不可能ですし、セキュリティには費用がかかります。従って、価値の高低を判断し、価値が高い情報は厳重に保護し、価値が低い情報は緩く保護します。
　システム開発の初期段階では、ひとまず段階的評価するところから始めます。情報システムの性質にもよりますが、利便性を考えると5段階評価ぐらいの粒度が好ましいと思います。なお、情報資産の評価は、開発側とユーザー側の双方が行うべきです。何故ならば、情報の価値は立場により異なり、クラッカーはその盲点を利用して犯罪を実行するからです。
　例えば、ユーザーが価値を見いだせないシステム設計に関する情報でも、クラッカーがその情報を利用してシステムをクラッキングできます。その逆に開発側が重視していない情報でも、ソーシャルエンジニアリングによるクラッキングが行われる可能性が十分にあります。それらの犯罪を防ぐために、多面的に情報資産を評価し、盲点をなくす努力をしなくてはなりません。一つの盲点がシステムの全てを駄目にします。情報セキュリティの実施は、慎重で抜け目ない姿勢で臨みます。

システム開発における情報セキュリティ3

　この記事はシステム開発における情報セキュリティ2の続きです。前回は概要を書きました。今回は話しを進めて、システム開発で最初にするべき情報セキュリティの取り組みについて解説します。
　最初にするべき事は守るべき対象である情報資産を明らかにする事です。守るべき情報が分からなければ、正しいセキュリティ対策は出来ません。これが、特定の工程でセキュリティ対策をしても上手くいかない理由です。
　情報資産とは、業務をする上で発生、もしくは必要となる全ての情報です。ニュースで顧客情報流出が大きく報道されていますが、大切な情報はお客様の個人情報だけではありません。業務に関する情報も同様に大事なのです。何故ならば、もし商品開発の情報を習得されれば、会社に深刻なダメージを与える可能性があります。また、業務の細かい情報も顧客情報や企業の機密情報を窃盗する為の糸口になります。
　情報資産を知る方法は、業務分析およびシステム情報の収集です。分析工程でユーザ企業の業務に関する情報を把握する事が出来ます。ですが、それだけでは不十分です。開発したシステムで新しい情報も発生します。その情報を情報資産として関する事が大事です。
　開発したシステムで発生する情報とは、新しい業務手順で発生する情報、システムの機能を達成する為に必要な情報、開発体制に関する情報などです。システムが新しくなると、自然と業務手順が変わり、それが原因で新しい情報が生まれます。また、セキュリティに関する事件が発生した際に、開発体制に関する情報を管理していれば脆弱性と犯人を絞れます。
　日本では事件が起こってから考え、「想定外」で済ませる傾向がありますが、情報セキュリティではその姿勢は致命的な誤りです。<間違いや事件が起こらない事を信じて待つのではなく、間違いや事件は発生する前提で考えます。それが情報セキュリティの基本姿勢です。想定外を想定するのが基本とも言えます。