はじめに
「セキュリティ対策をしよう」という漠然とした課題が挙がった際、どのように取り組めばいいかの1歩目でつまずいてしまった経験をお持ちの方は多いのではないでしょうか。
筆者は共通基盤の運用担当者として活動をしているのですが、定期的に受けているセキュリティ診断サービスで指摘を受けて修正をし、次の診断で前回とは異なる指摘を受けて修正するというサイクルに陥ってしまい、何とかして指摘を受けないように抜本的な対策を行う必要に迫られました。
しかしセキュリティ強化の検討にあたり、「何を保護するのか」、「どうやって保護するのか」、「決定した対策をどのように定着させるか」という点でつまずいてしまいました。
これらの内容が明確にならないとプロジェクト責任者から方針に対して承認を得られないどころか、共通基盤の利用者目線からもセキュリティに不安のある基盤として見なされ、需要が無くなってしまうという懸念があり大変苦労をしたことを記憶しています。
最終的に弊社内のアセットを活用して、上記の懸念を払拭しながらセキュリティ対策を進めることができたのですが、具体的にどのように進めたのかについてご紹介させて頂きます。
同様の悩みを抱えているシステム担当者や、セキュリティ対策の方針に不安を感じていらっしゃるプロジェクト責任者の方々にお役立ちできればと存じます。
セキュリティ対策の検討における課題
セキュリティ対策でつまずきやすいポイントとその原因について述べます。
①何を保護するのか
セキュリティ対策を計画する上で、まずは保護すべき領域を漏れなく定義することから始めようとしたのですが、そもそも保護領域を検討する際に参考となり得る情報が少なく、検討が思うように進みませんでした。
補足しますと、セキュリティに関しては、FirewallやSBOMといった個々のテーマではインターネット上で多数の情報を収集することができますが、漏れなくセキュリティ対策を行うために何をすべきかという全体観を検討する際によりどころとなる有用な情報をほとんど見つけることができませんでした。
②どうやって保護するのか
数多あるセキュリティサービスやツールにて、自システムに適しているものをどのように選定すればよいのかという点にも悩まれる方が多いかと思います。
サービスやツールが持つ市場シェア、ガートナー社等の調査会社の評価、クラウド事業者が提供するマネージドサービスなどから選定するということが考えられますが、自システムの目指しているセキュリティ強化方針に合致しているのか、自分達で運用できるのかという点でまだまだ説得力に欠けるものかと思います。
③どのように定着させるか
セキュリティ対策は有効な手段を継続的に行っていくことが必要ですので、各システムで脆弱性に対して是正計画を立て、実行し、事後評価といったサイクルを確実に回すことが重要です。
そのためには対応を属人化させないことや形骸化を防ぐことが必要ですが、徐々に対応が劣後され機能しなくなる恐れがあります。
共通基盤担当として各システムにどこまで働きかければこれらの懸念が払拭できるのかについても考える必要がありました。
属人化や形骸化が起きる要因として、「煩雑なオペレーション」、「セキュリティに対する感度の低さ」が挙げられるかと思います。
いかにオペレーションを明瞭にし、プロジェクト内のセキュリティ文化の醸成を図るかが鍵となります。
社内のアセットを活用した対策の検討について
①保護対象の明確化
セキュリティ対策の全体観の定義については、社内のアセットを活用して保護領域を明確にしました。
次に保護範囲の中で、共通基盤担当の責任範囲、アプリ担当の責任範囲を明確にしました。
※なお、著者のシステムではHTTPのネットワーク層はWAFで保護をしており、他の領域を漏れなく保護するためにはどうしたらよいのかを検討しておりました。
上記保護領域の定義に則り自システムの現状のセキュリティ対策の網羅性を評価し、セキュリティ対策が必要な範囲を定めました。
この保護領域の定義を活用することで、他のシステムにおいてもセキュリティ対策の網羅性を判断することが可能です。
②保護方法の検討
検討にあたり意識した点は、高度なセキュリティ有識者がいない組織であっても運用ができること、①で示したセキュリティ対策が必要な範囲を満たすソリューションであることの2点です。
特に、難しいチューニングをしなくてもデフォルトの設定で有効な脆弱性スキャンを実施できること、CWPP、CSPM、CIEMと広くカバーをする製品である“Prisma Cloud”や、アプリケーションの脆弱性検知を行う“Contrast”を選定しました。
これらの製品はグローバルで評価の高い製品でもあり、自社での導入実績もあります。
更に、POCで機能検証を行い、高度なセキュリティ有識者がいなくても活用でき、我々が正にやりたかったセキュリティ向上を可能にすることを確認しました。
なお、“Contrast”にはシフトレフト効果と呼ばれる脆弱性の早期発見効果も見込めます。
詳細はIASTでセキュリティテストをDXしよう！（DATA INSIGHT）をご参照ください。
③保護施策の定着に向けた働きかけ
著者のような共通基盤担当の場合、共通基盤を利用するシステムの担当者がセキュリティ対策を定型運用してもらえるように誘導することが最も大切なことです。
まず導入や設定に関する負荷を減らすため、基盤側で先に試行し、つまずきやすいポイントなどをまとめ、製品マニュアルの補助資料として展開しました。
次に、脆弱性を検知するとツールが自動的に重要度を示してくれるため、重要度別の対応基準を社内アセットを活用しながら設定しました。
現在は、スプリント単位で脆弱性検知⇒改修⇒是正といったサイクルを回せるよう、各システムの支援活動を行っております。
まとめ
新規システム開発時においては、非機能要件として重要なテーマとして「セキュリティ」の検討は必須でありますし、システム運用者においては日々進化するセキュリティ脅威に対して、自システムのセキュリティ対策の十分性を評価し、場合によっては対策を強化することはどなたもが経験することでしょう。
しかし、時間や人的コストなどの観点からセキュリティばかりに注力することは難しいと思いますので、なるべく手間をかけずにセキュリティ強化を実現したいというのがシステムに携わる方々の本音かと思います。
いざ、自分がセキュリティ対策を行う立場となった際に、本稿の内容が参考になりますと幸いです。
【ご参考】
本稿をご覧いただき、更にセキュリティに関心を持って頂いた方向けに“DevSecOps”についてご紹介致します。
“DevSecOps”の概念をご理解頂け、セキュリティに強い組織作りの参考になるかと存じます。
詳細はDevOpsをDevSecOpsに変えるには（DATA INSIGHT）をご参照ください。
※記載されている会社名、商品名、またはサービス名は、各社の登録商標または商標です。