前回の記事で「キラキラした専門職」という言葉を使いましたが、世間一般がイメージするセキュリティ対策は、WAFやIDSなどの防御系ツールやウィルス対策ソフトだと思います。確かにこれらは重要ですが、「それだけで十分か？」と問われると、答えは必ずしもイエスではありません。ここで登場するのが、いわゆる「レビュー」というプロセスです。
セキュリティレビューのイメージと現実
多くの人がセキュリティレビューと聞くと、まず思い浮かべるのはセキュアなコーディングとなっているか（コードレビュー）でしょう。しかし、私の仕事は少し違います。私が行うのは「設計書レビュー」です。しかも、技術的な正しさや仕様上の正確さではなく、企業のセキュリティ規程に照らして、準拠しているか、違反していないかを確認することが目的です。言い換えれば、レビュー対象は「システムの安全性」そのものではなく、あくまで「ルールに沿った設計かどうか」に重きがあります。
技術だけでは見えない視点
設計書レビューの面白いところは、技術的に正しくても規程に沿っていなければ指摘される点です。逆に、現場が便利だと思って工夫している部分が、規程とぶつかることも少なくありません。セキュリティと利便性は往々にして反比例するため、「これをやると業務が回らなくなる」「工数が膨大になる」と現場から意見が出るのは自然です。だからこそ、レビューの立場では単なる「正しい・間違っている」の判断ではなく、規程と現場のバランスをどう取るかが問われます。
設計書レビューの価値
こうした視点で設計書を見直すと、単なる防御技術の導入だけでは気づけない課題が浮かび上がります。例えば、パスワード管理の運用やアクセス権限の付与ルールなど、コードには現れないけれどシステム全体の安全性に直結する部分です。これを前もってレビューしておくことで、後になって手戻りが発生するリスクを大幅に減らすことができます。
つまり、セキュリティレビューは「技術的に正しいことを確認する場」ではなく、「規程に沿っているか、違反がないかを確認する場」と理解することが肝心です。コードレビューやツールによる防御ではカバーできない、現場の業務とセキュリティ規程の間にあるギャップを埋めるプロセス――これが設計書レビューの真価だと言えます。