レビューのあるべき姿

レビューにはさまざまな種類があります。例えば、法務の観点から個人情報保護法に違反していないかを確認するものや、キャンペーンの内容が景品表示法に違反していないかを確認するものなどがあります。

ここでは、システムセキュリティレビューに絞って考えていきます。

業務システムでは、新しいサービスの開始や業務要件の変更に伴い、新たな機能の開発や既存機能の変更が行われることがあります。また、自社の業務要件に変更がなくても、接続先サーバーの移行によって通信先が変わるなど、システムに変更が加えられるケースもあります。

システムセキュリティレビューでは、このようなシステムの変更がセキュリティ規程に準拠した形で実施されているかを確認します。

また、重要なのは、規程への違反を発見した場合、指摘するだけでなく、是正されるところまで確認することです。問題が是正されなければ、セキュリティ上のリスクが残ったままになってしまうからです。

ただし、システムの開発者も、ビジネス上の要件を満たし、定められた納期までに開発を完了させなければならない立場にあります。そのため、レビューを行う際には、次のような点に注意する必要があります。

レビュアーは設計者の敵ではない

開発側にとって、業務システムを正常に動作させ、求められる業務要件を満たすことは重要な目標です。その立場からすると、開発の途中でセキュリティ上の問題を指摘されることは、場合によっては、せっかく進めている開発に横やりを入れられたように感じられるかもしれません。

だからこそ、レビュアーは設計者の敵ではないということを意識する必要があります。両者は立場こそ異なりますが、安全なシステムを実現するという共通の目的を持っています。

指摘を行う際には、上から目線で一方的に問題を指摘するのではなく、なぜ是正する必要があるのかを丁寧に説明することが重要です。

単に「規程に違反しています」と伝えるだけでは、開発側も、なぜその対応が必要なのかを十分に理解できないことがあります。規程に適合していないという事実だけでなく、どのようなセキュリティリスクがあるのか、なぜ対策が必要なのかを説明することで、開発側も問題を理解し、対応の必要性を判断しやすくなります。

レビュアーの役割は、単に問題を指摘することではありません。リスクを明確にし、必要な対策や対応方針を整理して、適切な対応につなげることです。

一方で、指摘を行うレビュアー自身にも、心理的な抑制が働くことがあります。

「これを指摘したら嫌な顔をされるだろうな」「ここまで指摘する必要があるのだろうか」と考えてしまうこともあるでしょう。指摘をせずに済ませれば、開発側との摩擦を避けられるかもしれません。

その結果、本来指摘すべき問題を見過ごしたり、問題がないという結論に傾いたりすることがあります。

しかし、指摘をしなければ、その場で摩擦が生じることはなくても、セキュリティ上のリスクは残り続けます。そのリスクが将来的にどのような問題を引き起こす可能性があるのかを考えれば、対人関係への配慮を理由に指摘を控えたり、問題を見過ごしたりすることは避けなければなりません。

もちろん、指摘の数が多ければ良いレビューというわけでもありません。重要なのは、必要な確認を行い、問題があれば適切に指摘し、そのリスクが解消されたことまで確認することです。

レビューの目的は、指摘すること自体ではなく、セキュリティ上のリスクを適切に管理し、安全なシステムの実現につなげることにあります。