システム開発におけるセキュリティ対策は発注段階で詰めておこう

手のひらとSECURITY

更新日:2017年09月22日 | 公開日:2017年06月24日

インターネット上に構築されたシステムは、自社内で使うにせよ、取引先や一般消費者を相手にしたサービスで使うにせよ、セキュリティ対策が重要であることは広く認識されています。
しかし、ほとんどの会社が自社のセキュリティが脆弱であったという事実を認識するのは、ある日突然事件や事故という形で降りかかってきたときです。
システム担当者やwebマスターがセキュリティの専門家であったりすれば、日常的にセキュリティに関するログなどを解析していて「何かおかしい」という兆候を事前につかめることもありますが、多くの場合は事故が発覚してから対症療法的に対応していくことになるため、どうしても対策は後手に回ってしまいます。

「セキュリティ対策はサービスリリース後、しっかりした運用で実現していく」というスタンスの担当者の方が多いのですが、セキュリティ対策は早い段階で検討すればするほど効果が高いことは間違いがありませんし、実は運用フェーズで実現できるセキュリティ対策には、限界もあります。
また、設計段階でそもそもセキュリティが問題として出てこない方法で実装してしまう、というやり方もありますので、そうした知識については発注段階でしっかり認識しておき、開発会社と最善方法について検討したほうが良いでしょう。

この記事では先手のセキュリティ対策=発注段階で立てるセキュリティ対策について解説します。

あなたの会社に突然降りかかる悪夢のストーリー

悩む男性

例えば、以下のような悪夢のストーリーが、ECサイト統括責任者のあなたにある日突然降りかかってくるということも十分あり得るのです。

1. 発端~何かおかしいという知らせがある
セキュリティに問題があった場合、大抵それに最初に気が付くのは自分たちではなく、お客様であったり取引先であったりします。

ある朝出勤してメールボックスを開くと社内のwebマスターからメールが来ていた。
普段やり取りのあまりない部署からなので、何かな? と嫌な予感を抱きながらメールを開くと、こんな文面が踊っていた。

「今朝から当社のECサイトがまったく見られないというクレームが複数来ています。
メンテナンスとは聞いていないので、何か問題が生じているのではないでしょうか?」

2. 自分で確認して、システム部門に連絡を取る
嫌な予感を押し殺しつつ、自分でも自社のECサイトを見に行ってみる。
果たしてブラウザは真っ白のまま何も映らない。
webマスターの言ったとおりなのでシステム部門に連絡をしたものの、この段階ではまだ楽観的。

3. 社内のシステム専門家が悪い診断を容赦なく下す
技術担当者がサーバーの中身を検証してみると、ネットワークの回線状態が悪くて何も表示されないのではなく、表示すべき商品データそのものがデータベースから消されていることが判明。
他に被害はないか調査してみると、顧客データも消されており、個人情報を全件閲覧したあとで削除した履歴が残っていたため、顧客データが外部に流出した可能性が高いことが判明する。

4. 上司に報告すると、上司の顔が緊張で変わる
技術的なことには詳しくない上司は顔を強張らせながら、「どうなっているのか報告しろ」と怒鳴り散らすだけ。
技術者に詳しく調べてもらうと、インターネットに表示されるコンテンツを格納したデータベースと、顧客情報を格納したデータベースに悪意のあるSQL文(データベースにアクセスするためのプログラム文)を忍び込ませる「SQLインジェクション」が認められた。

5. 一部で蜂の巣をつついたような状況になりつつも報告書を簡単にまとめる
「SQLインジェクション」が原因らしいと技術者から報告を受けた段階で、日常的な運用、オペレーションに重大な過失があったのではなく、そもそもデータベースの設計時におけるセキュリティ対策が甘かったことが分かった。
しかし今は責任のなすり合いをしている場合ではないので、簡単に状況報告だけにとどめ、設計段階でセキュリティが甘かったことに関しては、別途落ち着いてから詳しい報告書をまとめることにした。

6. 状況報告を受けた上司はやっと事態を正面から受け止め、公式の見解を発表する
システムを一旦すべてストップさせた上で、不正侵入により顧客データが流出した可能性があることを公式に発表。
会社には問い合わせや非難の電話が殺到して、1週間程度通常業務にも支障が出るほどであった。
サイトはバックアップデータを使ってまる1日後に復旧したが、失われた信頼回復と今後のセキュリティ対策についてのビジョンはまだ見えてこない…。

悪夢のような事件ですが、こうした事態はセキュリティ対策が後手に回っている状態ではいつ起きてもおかしくありません。

発注段階でのセキュリティ対策の必要性について

セキュリティイメージ

この例から分かるように、セキュリティに関する問題は、普段どれだけ気を付けていたとしても、後手に回ってしまう傾向にあります。

これを避けるには、早い段階からセキュリティ対策を実施することが最も重要です。
では、早い段階とはいつのことでしょうか?
それはシステム稼働直後でも、システム納品時でもありません。
システムをゼロから作ることを発注した段階で、すでにセキュリティ対策を講じておくことが最も万全な対策だと言えるのです。

この悪夢のストーリーで原因として挙がった「SQLインジェクション」ですが、これはユーザーがテキストを打ち込むブラウザのフォームに、データベースを検索するための言語SQL(Structured Query Language)そのものを打ち込むことで実行できてしまいます。

通常ですとフォームに商品名や機能などと打ち込んで、該当する商品をブラウザに表示させるわけですが、データベース構築段階で、テキスト文以外のSQLの命令文は排除する仕様にしていないと「delete XXXX」というデータベースを消去するSQL文を書き込むことで、データベースの中身を消去できてしまいます。

このように、セキュリティ対策はシステムをリリースした後のんびり始めては手遅れ、というケースもありますので、発注段階でセキュリティ対策を明確にしておくことはとても大切です。
セキュリティ対策は後手に回ることが多く、遅れれば遅れるほど原状回復が困難となり、その間に顧客や取引先との信頼関係は損なわれていきます。

「セキュリティが甘かった」は運用ミスとは言い切れない

セキュリティマーク

「セキュリティが甘かった」という言葉を聞くと、普通は「ウイルスソフトを入れていなかったのか?」とか、「ウイルス定義の最新アップデートを怠っていたのか?」といった主に運用面でのミスを連想しがちです。
確かにウイルス対策は日々の運用面でのアップデートが欠かせませんし、ほかにも社員が不用意に持ち出したノートパソコンを社外で紛失したり、重要な情報を複製した記憶メディアが盗難にあったりすることはセキュリティに関する運用ミスと言えるでしょう。

こうした運用上のミスに関してミーティングを開き、注意深く事細かく禁止事項を作って今後の運営に反映させていくという態度は大切です。

しかし、冒頭の「SQLインジェクション」の例から分かるように、セキュリティ問題の原因は運用だけにあるのではありません。

確かに、例えば納品されてから半年や1年と問題なくシステムは動いていたのにある日突然セキュリティ問題が発生したという状況を前にすると、原因が発注時あるいはその前段階にあるとは考えにくいかもしれません。
それでも「上流工程でのリスク分析や対策が十分でなかったために、納品後時間が経ってからセキュリティ問題が浮上したのではないのか?」と疑ってみることが大切です。

先程の運用ミスの例として挙げたセキュリティソフトのアップデートに関しても、セキュリティアップデートがなされていないシステムは、アップデートが完了するまでサービス公開できない仕様にしたりすることもできますし、ノートパソコンを社外に持ち出しても社外からはアクセスできない仕様にすることもできます。
また、特別な権限のないスタッフは記録メディアにデータを移すことができないようなセキュリティを設計段階で盛り込むこともできます。

このように考えると、あとからセキュリティが甘い状態の部分を防御するのではなく、そもそも設計・実装の段階でセキュリティ的に甘い状態を作らないようにしておく手段を取ることが一番望ましいということが分かります。

事後診断でも分かる、事前にセキュリティリスクの芽を摘むべきだった例

悩む女性

すでにリリースしてしまっているシステムでは、実際にセキュリティ問題が生じるまでそのリスクが分からない、というわけではありません。
理想としては発注段階でセキュリティリスクの芽は摘んでおくべきですが、稼働中のシステムもセキュリティ診断をすることによって脆弱性を明るみに出すことが可能です。

セキュリティ診断をすることで明らかになったセキュリティホールの例をいくつか見てみましょう。

管理画面に認証を経ずにアクセスできることが明らかになった

【稼働中システムの診断】
○X商事のサイトは、一般に公開されたBtoB向けのweb発注サイトと、社内の管理者向けのwebサイトに分かれて構築されていました。
管理者向けのwebサイトでは管理者のログインをIDとパスワードを入力させることで認証していました。
しかし、管理者向けサイトのトップページには認証システムがあるものの、一般ユーザー向けwebサイトのURLの途中に管理者サイトのURLの一部を入力すると、管理者用のwebサイトにダイレクトに入れてしまうことが判明しました。

【問題点】
このサイトの場合、ユーザー向けサイトURLの途中に/kanri/というディレクトリを挿入すると一般向けページを管理者権限で見られるようになっていました。
ダイレクトに途中ページから管理者用webサイトにアクセスした場合には認証なしで入れる状態だったわけです。
悪意あるユーザーがたまたまこのサイト構成のルールを発見してしまった場合、サイトの全ページが管理者権限で閲覧できます。
管理者権限で表示されたページからは管理者画面のトップページへのリンクボタンも貼られていましたので、トップページからの認証はないに等しい状態だったのです。

【設計段階にできたこと】
この脆弱性の原因としては、要求定義、要件定義が確定した段階で、リスク分析が十分に行われていなかったことが挙げられます。
例えばIDとパスワードのみで入口付近を防御するという設計ではなく、管理者用webサイトへは、SSLの電子証明書がインストールされたパソコンからしかアクセスできないなどの方法をとっていればこうしたセキュリティミスが生じることはありませんでした。

URLを複雑なアドレスにしておけば一般ユーザーに発見されないと思っていた

【稼働中システムの診断】
人事管理データをwebサイト経由で管理する社内システムを運営していたましたが、完全にクローズドで運営し、Googleなどの検索エンジンにもインデックス登録されないようにしていました。
URLも長い文字列を使い、一般ユーザーからは推測しにくいアドレスとしていたので、外部から検索されることもないと考えていました。

【問題点】
Googleなどの検索エンジンのインデックスを拒否する設定は、必ずしもすべての検索エンジンに対して有効ではないということや、ディレクトリトラバーサルという攻撃手法を使えば本来は公表されておらずアクセスも禁止されているディレクトリを閲覧できてしまうなどの事実を知らなかったのです。

【設計段階にできたこと】
ディレクトリトラバーサルに対する対症療法的な方法ではなく、人事データは社内でもごく一部のユーザーからしかアクセスする必要がないことを確認し、アクセス可能な部署(人事部など)のパソコンからのみ接続できるIPアドレス制限をかけるなどの方法がありました。

別ユーザーになりすまし可能になることが判明した

【稼働中システムの診断】
オンラインゲームを提供する○△システムズでは、ログインしたユーザーを識別するためのセッションIDを割り振るときに、連番で割り当ててしまっていました。
連番で当てはめると、現在悪意のあるユーザーに00050で割り当てられているとすれば、自分のセッションIDを00051に変えてしまうことで、まったく別のセッションを乗っ取ることができてしまいます。

【問題点】
ゲームサイトなので、マイページにはユーザー課金のためのプリペイドカードや、クレジットカードの情報などが記載されていたため、セッションを乗っ取った悪意あるユーザーが個人情報を悪用できる状態にありました。

【設計段階にできたこと】
別のページに移動しても、ログイン情報を保持するセッション機能を実装したところで満足してしまい、セッション機能がセキュリティホールになることに思い至らなかったことに問題がありました。
顧客情報という資産価値を防衛しようというセキュリティ対策をすべきだったのです。

要件定義フェーズでセキュリティ問題の芽を摘むためにやること

セキュリティマーク

今挙げたセキュリティ診断で明らかになった例は、本来、要件定義や設計段階で診断を実施しておくべきだったと言えます。
上流工程できちんとしたセキュリティ診断を行っておけば、問題は最小限に抑えられますし、そもそも問題が生じないような仕様にしてしまうことも可能です。

こうした上流工程でのリスク洗い出し作業にはセキュリティに詳しい社内のエンジニアや外部のセキュリティ・コンサルタントといったセキュリティ専門家による設計仕様書のレビューが欠かせません。
確かにその分費用はかかってしまいますが、セキュリティ対策を早い段階で行わなかったために、システムがリリースされてからセキュリティ問題が発覚し、結果的に大きな代償を払うというケースに比べれば取るに足らないコストである場合がほとんどです。

上流工程での診断サービスではどのようなことをするか

上流工程において、診断サービスではどのようなことをするのかをまとめみました。

主な診断項目
  • ユーザー認証方式のチェック
    連続してユーザー認証に失敗したときのアカウントロック機能や、不必要なリマインダ設定、なりすましサイトになりやすい特徴を持っていないかなどのチェックを行います。
  • セッション管理方式のチェック
    独自セッションIDの利用の有無やCookieの設定の脆弱性などをチェックし、別ユーザーになりすまされる危険性がないかをチェックします。
  • アクセスコントロール方式のチェック
    権限のない機能を不正に利用されたり、権限のない情報を不正に閲覧されたりしないためにあらかじめ対策がなされているかをチェックします。
  • フォームを使った入力データ処理方法のチェック
    ディレクトリトラバーサルや、SQLインジェクション、コマンドインジェクションなどに有効な「入力値チェック」や「入力データ無害化処理」ができているかをチェックします。
  • 暗号化方式のチェック
    通信経路上で重要データが暗号化されているか、暗号強度は十分かなどをチェックします。

開発会社と「セキュリティ設計図」を共有することが大切

パソコンで仕事をしている風景

上流工程でのセキュリティ診断を徹底することで、設計の中に盛り込むべきセキュリティ対策が見えてきます。
そのときに大切なのはセキュリティ対策の「網羅性」と「妥当性」を完備した「セキュリティ設計図」を開発会社と共有することです。

「網羅性」とは、最近話題になったセキュリティホールや、たまたま担当者が知っていたクラッキング手法などだけではなく、「このシステムでは設計の性質上こうしたセキュリティが弱くなる」という理論的な推論に基づいて、考えられるセキュリティの欠陥をすべて列挙することです。

当たり前のことですが、悪意あるクラッカーは対策をしていない部分のセキュリティホールを突いて攻撃を仕掛けてきます。
つまり90%の「網羅性」でセキュリティ対策をしていたとしても、残りの10%に不備があった場合にはそれ以外の90%の対策は無駄になってしまうわけです。

「妥当性」については、「網羅性」の原則に従って洗い出した要セキュリティ対策箇所に対して、適切に対応しているかどうか確認します。
セキュリティホールを洗い出すことができても、開発会社の知っている対策方法が古かったり、十分でなかったりする場合には、せっかく設計段階でセキュリティ対策を始めても不完全な状態でシステムが完成してしまいます。

設計段階のセキュリティ診断では、診断したあとにきちんとした対応策を立てられる実績を持った業者を選定しておく必要があります。

開発者目線ではなく発注者目線を持った業者に診断してもらうことが大切

「網羅性」と「妥当性」を完備した「セキュリティ設計図」を開発会社と共有するためには、業者選びが非常に大切になってきます。

というのも、「網羅性」の原則を満たしてセキュリティホールを発見するためには、広い視野に基づいて最新のセキュリティ事情に関して適切な知識を持っていることが前提条件となるからです。
特定の部分に強いエンジニアはたくさんいますが、「網羅性」を満たした適切なセキュリティ診断を行うためには、エンジニアの属人的な知識や経験だけでなく、組織として情報収集や蓄積を行っている必要があります。

また「妥当性」についても、1人のエンジニアだけが担当すると狭い視野で個々の対策を考えることに終始してしまう傾向があります。
「このケースではこの技術を使う」「このケースではこういう対策をとる」という定番の対策手法は知っていても、セキュリティ関連は毎日のように新しいウイルス対策アップデートが出てくるような世界です。
対策の妥当性も1年前の常識と今日の常識にはずれがあって当たり前です。
新しい状況に関して適切な判断を下せる力量を持ったエンジニアチームでないと、おざなりの対策になってしまう可能性は十分あり得ます。

どのようなセキュリティホールが想定されて(網羅性)、それについてどのような対策を立てるつもりなのか(妥当性)について、開発会社に丸投げすることなく発注側企業が積極的に設計図づくりにコミットすることが大切です。

「セキュリティ設計図」の作成7ステップ

「セキュリティ設計図」は段階を追って次のステップで作るのが一般的です。

ステップ1. 資産価値の決定

「セキュリティ設計図」作成を開発業者に丸投げしてしまった場合、この記事の冒頭にあった例ですと、「フォームを使うからSQLインジェクション対策をします」という個別の対策手段を実装するところからいきなり始まってしまいます。

しっかりしたセキュリティ設計図を作成するためには、まず発注側企業が持つ「資産価値」を決定するところから始めます。
いったい保護すべきものは何か、そして保護すべき優先順位はどうなるかについて企業の資産価値を棚卸しします。

当然この作業をするには、システムを構築したときに守るべきどんな資産があるのかを発注者側が列挙していく必要があります。
そして資産を列挙するときには、どのような利用者(アクター)が想定されるのかも洗い出します。

ステップ2. リスクの分析

リスクの分析段階では、この記事でも取り上げた「不正アクセス」や「情報漏えい」などのリスクを「網羅性」の原則で列挙していきます。
このとき、ステップ1の「資産価値の決定」で行った資産の洗い出しで出てきたデータを活用します。

つまり、「フォームを使うからSQLインジェクション対策をします」という現象面からリスクを分析するのではなく、「顧客データベースという対象(資産価値)に対して、一般ユーザー(アクター)が不正な操作(SQLインジェクションなど)をするケースがある」という、資産を軸としたリスクを分析します。

当然、SQLインジェクション以外にも顧客データベースに対する脅威は残ります。
例えば、「内部スタッフ(アクター)によって顧客データベースという対象(資産価値)が持ち出される(情報漏えい)」といった脅威もあります。

「SQLインジェクション」という現象面からのみリスクを分析した場合には、こうした情報漏えいからの顧客データベースのリスク分析は出てきません。
発注者の持っている資産価値を軸にリスク分析をすることで「網羅性」が担保されます。

また、一般ユーザー向けwebサイトのURLに一部文字列を追加すると管理用webサイトにアクセスできてしまうというセキュリティホールについても、「サイト運営上の管理データ(資産価値)に対して一般ユーザー(アクター)がアクセスできてしまう(認証不備)」という分析ができますし、「サイト運営上の管理データ(資産価値)を管理しているノートパソコンを管理者(アクター)が社外に持ち出して紛失してしまう(情報漏えい)」という分析も可能です。

これも、「一般サイトからの不正アクセス」という現象面からだけサイト運営上の管理データを観察した場合には出てこない分析です。

サイト上の運営データを社外に持ち出してしまうケースは、管理者がノートパソコンを持ち出す以外にも、悪意を持ってリムーバブルディスクにデータをコピーして持ち出すというケースもあるでしょう。
そうした場合には、オペレーションルームへの入退室監査や監視カメラ設置、端末操作ログ監査などの対策が必要になってきます。
これらの対策手段も、資産(サイト上の運営データ)を防衛するという視点があって初めて浮かび上がってくる対策です。

ステップ3. セキュリティ要件をリストアップする

「資産価値」を軸にリスク分析を行うと、必要なセキュリティ要件が出揃います。
セキュリティ要件が出揃った状態で「網羅性」は完備されていますので、次に「セキュリティ対策の重要度」の順にリストアップします。

「セキュリティ対策の重要度」は、もし「資産価値」がリスクにさらされた場合、どのくらいの被害が起きるかというリスクレベルを計算することで出てきます。

例えば、「顧客データ」という資産価値は、「従業員名簿」の流出よりも重要度が高いので、上位の資産価値を持つものとしてリスト化します。
さらに、公開した一般ユーザー向けwebサイトがつながりにくくなるという、不正アクセス集中攻撃である「DoS攻撃」よりも、顧客データの消去があり得る「SQLインジェクション」の方がリスクレベルが高いと言えます。
これも、もし攻撃を受けた場合の被害の大きさがどれくらいになるかによって優先順位の高い方からリストアップします。

そして、「資産価値」×「リスクレベル」で「セキュリティ対策の重要度」の計算を行います。

例えば、「顧客データ」×「SQLインジェクション」の「セキュリティ対策の重要度」は極めて高くなりますし、「従業員名簿」×「Dos攻撃」の「セキュリティ対策の重要度」は極めて低くなります(web経由で従業員名簿が一覧できない/画面が出てくるのに時間がかかるなど被害は限られる)。

こうして、重要度順に網羅性を持ったセキュリティ要件がすべてピックアップされます。

ステップ4. 「概念レベル」の設計

セキュリティ要件がピックアップされたあとは、個々の要件ごとにどんなセキュリティ技術が求められるかを検討します。
具体的には「認証強化」であったり「アクセス制限」であったりします。

概念レベルの設計を行うためには、「セキュリティゾーニング」を行って、インフラ全体を整理します。
セキュリティゾーニングとはもともと、物理的なオフィスのセキュリティ確立のために入退室のドアや鍵、部屋への経路などを設計するときに使われていましたが、システム構築上もサーバーやネットワーク機器などのノードを集約して考えるときに使われます。

アプリケーションの実行に伴う情報の流れを十分に分析して、データベース部分、ネットワーク部分などの脅威を整理することで必要な対策が浮かび上がってきます。

ステップ5. 「設計レベル」の対策

「設計レベル」の対策では、個々の現象面に注目します。
SQLインジェクションで言えば、ここで初めて「フォームを使っているのだから、フォームにSQLのコマンドが打ち込まれた場合に入力を無効にする」などの方法の検討がなされます。

管理者用webサイトへの一般サイトからのアクセス問題では、認証の強化を行うための方法や、そもそも一般ユーザーがアクセス可能な外部ネットワークからは、管理者用webサイトにアクセスできないようにIPアドレスレベルでシャットアウトする、などの設計を行います。

ステップ6. 「実装レベル」の対策

「実装レベル」の対策では、例えばSQLインジェクションの場合には、データ入出力時に不正なコマンドをはじくプログラムを埋め込むような対策がとられます。
その他、オリジナルのプログラムコードを埋め込むような対策以外にも、具体的なセキュリティ対応製品をピックアップして、製品を導入するなどが考えられます。
もちろん、既存のセキュリティ製品で対応して切れない部分はオリジナルのプログラムコードを付け加えるなどのカスタマイズが必要になります。

ステップ7. 残存リスク対策

このように、セキュリティ対策は発注段階でかなりの部分に有効な手立てを講ずることが可能です。
セキュリティ対策はシステムが納品されてからボチボチ考える…というスタンスは間違っていることがお分かりいただけたと思います。

理想としては発注段階で完全に解消したいセキュリティ対策ではありますが、どうしても取りこぼし部分は出てきます。

残存リスク対策としては、下記の3つ方法のどれかを講ずることになります。

残存リスク対策
  • 追加のセキュリティ対策を行う
    要件のリストアップはされていたが、優先順位が低かったので実装していなかったという場合には、早急に実装します。
  • ポリシーなどの運用ルールで規制する
    設計段階でまったく考慮されなかった新型の攻撃手法などに対応する場合などは、まず運用ルールで対処しておき、次回のバージョンアップ時などに抜本的な対策を行います。
  • リスクを認知して静観する
    現段階で直接的な被害が出る可能性は極めて低いが、次回のバージョンアップ時にリスク要件として検討するためのリストを作っておきます。

発注段階のセキュリティ対策をセキュアな運用計画につなげる

パソコンのキーボード

発注段階で開発会社と共有された「セキュリティ設計図」は、開発段階で開発会社の実装へと引き継がれますが、もちろんそこでセキュリティ対策がすべて完了するわけではありません。
先程の「セキュリティ設計図」のステップ7で確認したように、日々の運用のなかでセキュリティ対策を維持することが不可欠になるのは仕方ない部分でもあります。

「セキュリティ設計図」は初期の設計と実装のための仕様書であるだけでなく、運用時のセキュリティ対策の手引書ともなります。
発注段階で「セキュリティ設計図」を作成し、その共有を開発会社と徹底することで運用段階で後手に回った形で行うことになるセキュリティ対策はかなりの部分が減らせますが、それでもまったくゼロにすることはできません。

しかし、発注側企業と開発側企業で徹底してリスク分析を行った「セキュリティ設計図」は、極めて実用度の高いセキュリティ運用ポリシーとして使えるのです。

以下に、その例を挙げます。

ユーザー認証を設計通り徹底する

設計段階でユーザー認証周りについて完璧な対策を立てても、実際にシステムを運用する段階で、個々のユーザーがずさんな認証管理をしていたのでは元も子もありません。

権限によってログインできるサイト先まで細かく設定したにも関わらず、権限の高いIDとパスワードを自分の出張中に引き継ぎを頼んだ部下にメモで渡してしまったり、1ヵ月に1度パスワードを変えるというセキュリティポリシーを遵守していなかったりなど、運用面において当初の設計どおりの認証強度が守られているかをチェックすることが大切です。

「最小権限の原則」を設計通り徹底する

「最小権限の原則」とは情報セキュリティ用語で、場面に応じて必要最小限の権限だけを与えるようにする原則を指します。
セキュリティリスクを最小限に抑えるためには、最初のTOP画面で管理者用サイトへの認証を許可されたユーザーであっても、業務上不必要な領域にはアクセスさせないことが大切です。

例えば、webの管理者権限を持つwebマスターは、ホームページの画像やテキストなどのデータにはフルアクセスできることが必要ですが、日常的に顧客の個人情報にアクセスする必要はありません。
顧客からの問い合わせなどで運用上どうしても必要な場合には、顧客管理を担当する責任者が個人情報にアクセスするなどの、役割に応じた「最小権限の原則」が大切になってきます。

また、webデザイナーが画像やHTMLページにアクセスできることは必要ですが、データベースの作成やテーブル構造の変更などの権限を持つ必要もありません。
逆にデータベース管理者がホームページのテキストデータや画像にアクセスする必要もありません。

こうした細かな権限設定を、設計時にすべて完成させておくことは現実的ではありません。
認証のセキュリティは設計段階できちんとセキュアなレベルを確保しておけますが、誰がどのデータにアクセスできるかという「アクセスコントロール」の設定は、運用しながら柔軟に設定していくことが効率的でしょう。

各種ログの収集によるチェック

今見てきた「ユーザー認証」や「アクセスコントロール」を日々の運用でチェックしていても、セキュリティが破られる可能性はゼロにはなりません。

運用段階で重要になってくるのは、セキュリティが破られる兆候を早い段階で察知することです。
そのためには、各種サーバーのログを収集・保管した上でセキュリティ監査を実施することが必要になります。

収集・保管、監査に必要なログの種類
  • 認証ログ
    どのパソコンからログインしたか、ログインに失敗したかを記録します。
  • 端末操作ログ
    ログイン後、どのファイルを閲覧したか、どんなサービス・ソフトを使ったかなどを記録します。
  • イベントログ
    オペレーションシステムレベルの各種セキュリティ情報が登録されます。
  • 通信ログ
    通信状況や通信中のエラー状況などを記録します。
  • 設定変更ログ
    権限変更を行ったり、セキュリティレベルの変更を行ったりしたときのログとなります。

これらのログを解析するには、専用ソフトを利用したり専門の人員を確保したりすることが必要になる場合もあります。

万が一セキュリティが破られたときのことも発注段階で考えておく

パソコンで仕事をしている男性

ここまで発注段階でセキュリティの設計図を詰めておくことの重要性とともに、その設計図をもとにした実用性の高いセキュリティ運用計画について解説してきました。

これまで説明してきた内容で、事前に講じておくべきセキュリティ対策は網羅していると言えますが、万が一の最悪のケースも想定しておくことで、セキュリティ対策は最終的に完成します。

冒頭に挙げたある日突然サイトが表示されなくなった例をもう一度確認してみましょう。
下記の流れは、発注段階でセキュリティの設計図作成などを行わなかった企業で対応が後手に回ったときの例ですが、対応をしていた企業においても、万が一のケースで取るべき具体的な対処方法となります。

流れのポイントはこうなっています。

セキュリティが破られた時の対応
  • 【検知】
    発端~何かおかしいという知らせがある
  • 【初動対応】
    自分で確認して、システム部門に連絡を取る
  • 【調査分析】
    社内のシステム専門家が悪い診断を容赦なく下す
  • 【関係各部署への報告】
    上司に報告すると、上司の顔が緊張で変わる
  • 【公式見解と謝罪の準備】
    一部で蜂の巣をつついたような状況になりつつも報告書を簡単にまとめる
  • 【外部への情報開示及び謝罪】
    状況報告を受けた上司はやっと事態を正面から受け止め、公式の見解を発表する

冒頭の例では「失われた信頼回復と今後のセキュリティ対策についてのビジョンはまだ見えてこない…。」と結びましたが、こうした流れを想定して、手順をドキュメント化しておくなどの先手の対応をとっておけば、信用失墜は最小限に食い止めることができます。
また、今後のセキュリティ対策の指針もいち早く再構築できるでしょう。

セキュリティ問題の責任範囲を明確にしておく

ここからは上記の続き、7となりますが、なぜこのようなことが起きたかについて開発会社と話し合いの機会を持ち、責任を明確化する必要があります。
例えば、システムを調査してみたところ設計どおりにセキュリティ対策が実装されていなかったという場合には開発会社に対して法的、金銭的な責任を問うことができます。

また、開発会社では設計に従って必要なセキュリティの実装も行っていたが、運用面で大きなミスがあった、という場合には内部でさらになぜそのような事態が起きたのか、関係各部署の責任を明らかにして再発防止に向けた取り組みをスタートさせることが必要です。

いずれにしても、こうした最悪の状況が生じた場合についても、発注段階でドキュメントを準備しておくなどの先手の対応をとっておくことがベストです。

【まとめ】セキュリティ対策は発注段階ですべてやっておく

パソコンとメモ帳と砂時計

以上、後手に回りがちなセキュリティ対策を発注段階で詰めておく必要性や、その具体的な方法について解説しました。

これからシステム構築を考える企業の担当者の方にぜひ持っておいていただきたい意識としては、セキュリティ対策は早ければ早いほど効果があるし、費用も安く済むということです。
そして、その「早い」ということを「導入したらすぐ」と考えてしまう担当者の方が多いのですが、それではすでに遅いのだ、という意識を持っていただきたいと思います。

設計段階で潰せる(そもそもセキュリティ問題が起きない設計にしてしまう)セキュリティホールもたくさんありますし、運用面でカバーすることが必須だとしても、設計段階でどうしても取りこぼしの出てしまう要因のみを運用面に任せるという発想が必要です。

そして、それでもなお生じてしまったセキュリティ事故については、あらかじめ対応手順を文書化しておくことにより、最短時間で最適な対応をとることが可能です。
また開発会社との間に責任の明確化の基本的なガイドラインなどを作成しておくことで、スムーズな事態の収拾が図れます。
セキュリティ事故が生じてから対応方法を練ったり、責任がどこにあるかを議論したりすることを想像してみれば、事前にこれらの作業をしておくことのメリットがすぐにご理解いただけると思います。

ただし、システム開発会社はセキュリティ問題についての専門家ではない、というのが実情です。
セキュリティの設計や診断をプロジェクトの初期段階できっちり行ってくれる開発会社もありますが、多くは開発も終盤にかかった頃に「ところでセキュリティ対策や運用についてはどうしますか?」というおうかがいが営業担当者から投げかけられるといった状況です。

こうしたなか、先手のセキュリティ対策の重要性をきちんと理解して、診断や提案をしてくれる開発会社を見つけたい! という場合にはぜひ「アイミツ」にお声をおかけください。
信頼できるパートナーシップを構築できる企業をご紹介いたします。

いま知りたいこと
コンシェルジュが解決します!

コンシェルジュサービスは
3万社以上が利用している無料の相談サービスです。

コンシェルジュ

発注は時間も手間もかかりますよね?

コンシェルジュが解決します!

コンシェルジュに相談、あなたにあった業者を提案、発注の手間を削減!

完全無料

まずはお気軽にご相談ください