先週の金曜日、クラウドの「責任共有モデル」の話をしました。

要は、クラウド事業者は建物を守ってくれるが、自分の部屋の鍵は自分で守れ、ということです。

でも、ここで現実的な問題が出てきます。

「鍵をかけろ」って言ったって、クラウドの設定項目は数千あります。
AWS S3だけでも、バケットごとに数十の設定ポイントがあります。

人間が全部チェックして、「あ、ここ公開になってた」って気づくのは、ほぼ不可能です。

だから、今週は「機械に見張らせる」という飛び道具を紹介します。
それが「CSPM(Cloud Security Posture Management)」です。


CSPM = クラウドの「セキュリティ検査ロボット」

CSPM は何か難しいものではありません。

要は、24時間365日、クラウド環境をパトロールして、設定ミスがないか勝手にチェックしてくれるツールです。

毎日あなたがやるべき「見張り」を、ロボットにやらせるイメージです。

具体的には、こんなことを自動でやってくれます:

  • 「あ、このS3バケット、全世界に公開されてますよ」
    → アラートを飛ばす、あるいは「非公開」に自動修正
  • 「このセキュリティグループ、ポート22(SSH)が全世界から開いてますね」
    → 「このままだと危ないですよ」と教える
  • 「このユーザー、多要素認証(MFA)が設定されていません」
    → 「MFA を強制しますか?」と提案する

つまり、**「設定ミスは事故ではなく、仕組みで潰すべきもの」**という考え方を実装するツールです。


CSPMがなぜ「火曜(経営)」と繋がるのか

ここで気づいて欲しいのは、CSPM は単なる「セキュリティツール」ではないということです。

火曜日の記事で、「調達を段階的にしましょう」「小さく始めて事実を見ましょう」という話をしました。

クラウドで段階的に進めるには、「毎回、設定ミスを事故にしない仕組み」が絶対に必要です。

CSPMがあれば

開発チームは「細かく詰めなくていい」
完璧な仕様書を書く時間を短くできます。代わりに CSPM が監視します。

経営は「ミスで吹っ飛ぶ心配をしなくていい」
セキュリティ事故のリスクが見える化され、自動で対応されます。

金曜日のセキュリティ担当は「寝不足にならなくて済む」
24時間のパトロールをロボットが代わりにやります。

つまり、CSPM は「経営のスピード実現」と「セキュリティの両立」を可能にするツールなんです。


「設定ミス」の典型パターン

実際に何が起きているのか、よくある事例を見てみましょう。

設定ミス原因被害
S3/GCSの公開設定「テスト用だから一時的に全公開にした」→忘れた顧客リスト、個人情報流出
セキュリティグループ(ファイアウォール)「開発が速いようにと、全ポート開放」→本番でも放置サーバー乗っ取り、ランサムウェア
IAM権限の過剰付与「一時的に強い権限をあげた」→定期レビューなし離職者が権限使い続ける
暗号化なしでデータ保存「設定が複雑だから後回し」→忘れた規制当局からの厳重注意

ぜんぶが「意図的な悪さ」ではなく、「一瞬の判断ミスが積み重なった」ものです。

だからこそ、人間の「気をつけ」に頼るのではなく、機械に継続監視させるべきなんです。


今週、現場がやるべきこと

CSPM は高いツール(月数万円程度)もあれば、クラウド事業者が無料で提供する基本機能もあります。

いきなり導入を決める必要はありませんが、「今どうなっているか」を少なくとも1回は調査すべきです

チェックリスト(1時間でできる)

① S3/GCS のバケット設定を確認
「Bucket Policy」に "Principal": "*" が書いてないか? → これは「全世界公開」です。

② セキュリティグループ(AWS)の Inbound ルール確認
ポート22、3389(RDP)が 0.0.0.0/0(全世界)から開いてないか?

③ IAM ユーザーの MFA 設定確認
「管理者権限を持ってるのに、パスワードだけ」という人がいないか?

④ ストレージ内のデータが暗号化されているか
AWS なら「Enable Server-Side Encryption」が ON になってるか?

これを確認して、「あ、ヤバい設定があるな」と気づいたら、来週からの CSPM 導入を経営に提案してください。


問いかけ

クラウド環境、最後に「設定の総合チェック」をしたのはいつですか?

「導入した時だけ」「監査の時だけ」だとしたら、その間、ずっと「鍵が開いている可能性」があります。

来週の火曜日は、金融業界が「規制が敵ではなく、攻めるための土台」に変えた話をします。


参考資料