こんにちは。かわばたです。最近は居酒屋で飲食したあとに個人情報を紛失するニュースをよく聞くようになりました。私自身は会社の個人情報を持つことはないですが、会社で支給されているPCを持っている時は、運転と同じで「飲んだら持つな、持つなら飲むな」を心がけてます。「飲んだら持つな」と言われても居酒屋に置いていくわけには行かないので、基本的に飲まないのですが。。。閑話休題。
私が所属しているチームでは、AWSでのセキュリティガードレールの実装と運用を担当しています。
弊社ではデータ活用などが増えGCPを選択しているプロジェクトも多く存在しており、GCP に対するセキュリティやガードレール敷設も必要になってきます。
今回の記事はその仕組みをGCPに導入するために模索したときの内容となります。
AWSのセキュリティガードレールの運用
現在運用しているセキュリティガードレールは大きく分けて２つのパターンがあります。
手動修復
手動修復とは、セキュリティ違反しているリソース変更操作を検出して担当者に通知し、通知を受けた担当者が、セキュリティ違反しているリソースを修復かつ必要に応じて操作禁止の設定を行うまでの流れを指します。 Config でリソース変更操作を検出して Security Hub のAWS基礎セキュリティベストプラクティスで評価して違反項目を発見します。 Eventbridge, SNS, Chatbot を経由して Slack で担当者に通知し、通知を受け取った担当者は発見された違反項目を手動で修復かつ必要に応じて Organization, IAM などを利用して操作禁止にします。
自動修復
自動修復とは、セキュリティ違反しているリソース変更操作をトリガーとして、プログラムによりリソース変更操作を修復するまでに流れを指します。Config から Config Rule で違反項目を発見し SSM Automations で自動修復プログラムリソース変更操作の修復を実行します。
自動修復の場合、必要に応じて SSM Automations → Lambda と連携したり、 Config Rule を使用せず Security Hub → Event Bridge → Lambda と連携して自動修復しているパターンがあります。
現在運用しているセキュリティガードレールのイメージは図のとおりです。
図の右下のほうの 手動修復, 操作禁止 については、担当者が手動で行う操作なので今回の調査の対象外とします。今回は 通知の仕組み（変更操作検出→通知) と 自動修復の仕組み（変更操作検出→自動修復） を対象に、GCPでどのようにセキュリティガードレールを設定するか調査しようと思います。
通知の仕組みの調査
AWSの通知の仕組み
AWSの通知の仕組みは以下の図の通りです。例として「RDSがパブリック公開されている」というセキュリティ違反をした場合のフローとなっています。
Slackでは以下のように通知されます。
AWS・GCPサービスの比較（通知）
この仕組みを用途別にAWS・GCPを比較すると以下のようになります。
| 用途 | 説明 | AWSサービス | GCPサービス |
|---|---|---|---|
| 変更操作検出 | リソース変更操作を検出 | Config | Security Command Center |
| 違反項目発見 | セキュリティガードレールに違反している項目を発見 | AWS SecurityHub | Security Command Center |
| 検出項目連携 | SCCで検出された違反項目を、別プロジェクトのPub/Subに連携 | - | NotificationConfig |
| 通知連携 | 違反項目をSlackへ通知 | EventBridge, SNS, Chatbot | Pub/Sub, Cloud Functions |
検出項目連携 用途の機能はGCSのみにあるのですが、 Security Command Center のスタンダードティアで通知するために必要設定となります。
GCPの通知の仕組み
GCPの通知の仕組みは以下の図の通りになります。設定は Pub/Sub の検出結果の通知を有効にする と リアルタイム メールとチャットの通知を有効にする を参考にしました。 例として「CloudSQLがパブリック公開されている」というセキュリティ違反をした場合のフローとなります。
Slackでは以下のように通知されます。Cloud Functions で実装しているので通知内容はカスタマイズできます。
自動修復の仕組みの調査
AWSの自動修復の仕組み
AWSの自動修復の仕組みは以下の図の通りです。
AWS・GCPサービスの比較（自動修復）
この仕組みを用途別にAWS・GCPを比較すると以下のようになります。
| 用途 | 説明 | AWSサービス | GCPサービス |
|---|---|---|---|
| 変更操作検出 | リソース変更操作を検出 | Config | Security Command Center |
| 違反項目発見 | セキュリティガードレールに違反している項目を発見 | Config Rule | Security Command Center |
| 検出項目連携 | SCCで検出された違反項目を、別プロジェクトのPub/Subに連携 | - | NotificationConfig |
| 通知連携 | 自動修復のトリガーとなる違反項目を連携 | - | Pub/Sub |
| 自動修復 | 違反したリソースを修復 | SSM Automation | Cloud Functions |
GCPの自動修復の仕組み
GCPの仕組みは通知の仕組みとほぼ同じで以下の図の通りになります。AWSの Config Rule や SSM Automation のようなサービスはなく、自動修復処理を Cloud Functions で実装することで自動修復できそうです。（時間の関係で未検証）
まとめ
今回の調査では通知の仕組みについては検証が完了しているので導入できることが確認できました。自動修復の仕組みについては未検証なのですが Cloud Functions で実装すればできるのではないかと思われます。引き続きGCPにセキュリティガードレールが導入できるよう検証を進めていこうと思います。
