システム開発におけるセキュリティ対策は発注段階で詰めておこう【2024年最新版】

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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