セキュリティレビューの目的は「ミス探し」ではない
セキュリティレビューという仕事に対して、「ミスを探して指摘する仕事」というイメージを持たれることがあります。
もちろん結果として問題点を指摘することはありますが、本来の目的はそこではありません。
レビューの目的は、企業として「何を守りたいのか」「何を担保したいのか」に従って決まるものだと思っています。
例えば、開発レビューであれば、バグを減らして品質を向上させることが目的になるでしょう。
性能改善が目的なら、無駄な処理を削除したり、高速化したりすることが重要になります。
では、セキュリティレビューの目的は何か。
私の現場では、外部攻撃や内部不正による「重要情報の大量漏洩防止」が大きな目的になっています。
セキュリティで何を守るのか
セキュリティの世界では、昔からCIAという考え方があります。
- Confidentiality（機密性）
- Integrity（完全性）
- Availability（可用性）
の3つです。
私の仕事では、この中でも特に「機密性」を重視しています。
事業を行ううえで、顧客から預かった個人情報や重要情報を漏洩させないこと。
これが重要なテーマです。
一方で、業界によって重視されるものは変わります。
例えば金融系のシステムでは、データ改ざんを防ぐ「完全性」がより重要になる場面もあるでしょう。
また最近では、ランサムウェア攻撃の影響もあり、「可用性」、特に事業継続性の重要性も非常に高まっています。
つまり、「セキュリティ」と一言で言っても、何を守りたいのかによって見るべき観点は変わるということです。
なぜ規程準拠を確認するのか
では、重要情報の大量漏洩を防ぐために何を確認するのか。
そこで登場するのが「規程」です。
規程には、
- 外部との境界にファイアウォールを設置する
- 適切な認証や権限制御を行う
- 作業ログを取得・監査する
- 通信を暗号化する
といった、「守るべきルール」が定められています。
これらは単なる形式的なチェック項目ではなく、過去の事故や攻撃事例、リスク分析などを踏まえて作られているものです。
設計書レビューでは、システムがこれらの規程に準拠しているかを確認します。
つまりレビューとは、「ルール違反を探すこと」そのものが目的ではなく、漏洩リスクを下げるために必要な対策が取られているかを確認する活動なのだと思っています。
「レビューOK＝安全」ではない
ただし、ここは誤解されやすいところでもあります。
レビューでOKになったとしても、「安全が保証された」という意味ではありません。
どれだけ対策をしても、リスクをゼロにすることはできませんし、想定外の攻撃や運用ミスが起きる可能性もあります。
レビューによってできるのは、あくまで「一定のリスク低減」です。
それでも意味があるのは、何も対策しない状態と比べれば、漏洩や事故の可能性を下げられるからです。
セキュリティレビューは「安心感を作る仕事」なのかもしれない
ある意味では、セキュリティレビューは「安心感を作る仕事」なのかもしれません。
ただ、その安心感が「レビューOKをもらったから何が起きても大丈夫」という方向に使われてしまうと危険です。
開発現場では、ときどき「レビューを通したから問題ないですよね？」という空気になることがあります。
でも、本来レビューは“免罪符”ではありません。
重要なのは、
- なぜそのルールが存在するのか
- 何を守るための対策なのか
- どのリスクを下げようとしているのか
を、開発側もレビュー側も理解したうえで進めることだと思っています。
レビューを単なる通過イベントにしないこと。
それも、セキュリティ文化を作るうえで大事なことなのだと思います。