【入門編】 ISO/IEC 27001:2022におけるクラウドセキュリティ管理策の適用 – ガバナンス・リスク管理 & 生成AIセキュリティ防御ガイド

こんにちは！インフラや開発の現場に飛び込んだばかりの新人IT担当者や、「セキュリティって何から始めればいいの？」と少し戸惑っている一般開発者の皆さん。日々の開発や運用、本当にお疲れ様です。

セキュリティの世界って、聞き慣れない専門用語や分厚いガイドラインがいっぱいで、最初はどうしても身構えてしまいますよね。でも、安心してください。一歩ずつ紐解いていけば、決して難しすぎるものではありません。

今回は、世界的なセキュリティの共通ルールである ISO/IEC 27001:2022 の中で、新しく追加されたクラウドにまつわる重要な管理策 「5.23：クラウドサービス利用のための情報セキュリティ」 と、それを現場でスマートに守るための 「CSPM（Cloud Security Posture Management）」 という仕組みについて、身近な例えを交えながら優しく解説していきますね。

一緒に、現場でそのまま使える実践的な設定のコツまで見ていきましょう！

—

1. 家の鍵に例える「クラウドセキュリティ管理策（5.23）」

まずは、クラウドサービス（AWSやAzure、Google Cloudなど）を使うときのイメージから膨らませてみましょう。

皆さんが引っ越しをして、新居の鍵を受け取ったとします。この新しいお家は、とても便利で家具も最初から揃っている「クラウドという名の賃貸マンション」のようなものです。ここで、あなた（開発者やIT担当者）と、マンションのオーナー（クラウド事業者＝CSP）の間には、大切な役割分担が存在します。

オーナーは「頑丈な外壁を作ること」「オートロックを壊れないように維持すること」を担当してくれます。これをセキュリティの世界では 「クラウドのセキュリティ」 と呼びます。
一方で、あなたがやるべきなのは「自分の部屋の鍵をちゃんとかけること」「窓を開けっ放しにして寝ないこと」「誰に合鍵を渡すかを管理すること」ですよね。これを 「クラウドにおけるセキュリティ」 と呼びます。

ISO/IEC 27001の2022年版で登場した 管理策5.23 は、まさにこの「賃貸マンション（クラウド）を借りるときに、オーナーとどんな約束を交わし、自分たちの部屋をどう安全に守るべきか」を定めたガイドラインなんです。

「クラウドだから全部安全でしょ」と油断して、部屋の鍵を開けっ放し（誰でもアクセスできる状態）にしてしまうのは、泥棒に対して「どうぞ入ってください」と言っているようなもの。だからこそ、この管理策をしっかり理解して、自分たちの身を守る必要があるんですね。

—

2. 泥棒は「うっかり」を狙っている！クラウドによくある落とし穴

攻撃者（泥棒）は、映画に出てくるような天才ハッカーばかりではありません。彼らが一番好むのは、私たちが日常でやってしまう「うっかりミス（設定ミス）」です。

例えば、こんな状況を想像してみてください。

テスト用に作ったデータベースの公開設定を、うっかり「世界中の誰でもアクセス可能」にしてしまった。
社員の誰かが、強力ではない簡単なパスワード（password123 など）のまま管理画面に入っていた。
退職したメンバーのアカウントが、そのまま残しっぱなしになっていた。

これらはすべて、家の窓に鍵をかけ忘れたまま旅行に出かけるような危険な状態です。サイバー攻撃者は、自動化されたツールを使って、インターネット上の「鍵の空いている部屋（設定ミスのあるクラウド環境）」を24時間いつでも探し回っています。見つかってしまったら、あっという間に機密データが抜き取られてしまいますよね。

—

3. CSPM（クラウドの防犯カメラ＆自動巡回システム）とは？

「でも、毎日すべてのサーバーやデータベースの設定を目視でチェックし続けるなんて、忙しくて無理！」って思いますよね。その通りです。人間の目だけで数千個もあるクラウドの設定を追いかけるのは不可能です。

そこで登場するのが、CSPM（Cloud Security Posture Management） というツールです。

CSPMを例えるなら、「自宅のセコムのような、24時間稼働の優秀な防犯カメラ＆自動巡回システム」です。
CSPMは、クラウド環境に接続しておくだけで、次のようなことを自動で行ってくれます。

「あれ？このデータベースの鍵（アクセス権）、誰でも入れる状態になっていませんか？」とリアルタイムでアラートを出してくれる。
「ISO/IEC 27001の基準に照らし合わせて、今の設定は合格点ですか？」とコンプライアンス（法令・基準遵守）を監視してくれる。
「ここをこう直せば安全になりますよ」という修正のアドバイスまで教えてくれる。

人間がうっかり忘れてしまったセキュリティの穴を、システムが代わりに見つけて怒ってくれる（教えてくれる）頼もしい相棒なんです。

—

4. 現場で使える！実用的なクラウド設定とIaCの例

それでは、実際にインフラを構築する現場で、どのようにセキュリティを担保していけばよいでしょうか。

現代の開発現場では、手動でサーバーをポチポチ設定するのではなく、コードとしてインフラを管理する IaC（Infrastructure as Code） が主流です。今回は、AWSのインフラをコード化する際によく使われる Terraform を例に、セキュリティを担保する具体的な設定を見てみましょう。

例えば、絶対に外部に公開してはいけないストレージ（バケット）を作る際の設定コードです。

# セキュアなクラウドストレージ（Amazon S3バケット）の定義例
resource "aws_s3_bucket" "secure_app_data" {
  bucket = "my-company-confidential-data-bucket-2024"

  # 【解説】不要なタグやメタデータを残さないよう、環境名を明記します
  tags = {
    Environment = "Production"
    ManagedBy   = "Terraform"
    Security    = "Strict"
  }
}

# 【重要】パブリックアクセスを完全にブロックする設定
# （家の窓を頑丈に閉ざして、外から中が見えないようにする泥棒対策の第一歩です）
resource "aws_s3_bucket_public_access_block" "secure_block" {
  bucket = aws_s3_bucket.secure_app_data.id

  block_public_acls       = true # パブリックACLをブロック
  block_public_policy     = true # パブリックバケットポリシーをブロック
  ignore_public_acls      = true # 既存のパブリックACLを無視
  restrict_public_buckets = true # パブリックなバケットアクセスを制限
}

このように、インフラのコード（IaC）を書く段階から「パブリックアクセスを禁止する」というルールを組み込んでおくことで、後からうっかり設定をミスして公開してしまう事故を防ぐことができます。

さらに、こうしたコードをデプロイする前に、TFLint や Checkov といった静的解析ツール（CSPMのミニ版のようなもの）をCI/CDパイプラインに組み込んでおけば、コードの段階でセキュリティ違反を検知できるようになります。

—

5. まとめ：一歩ずつ、安全なクラウド環境を作っていこう

今回は、ISO/IEC 27001:2022の管理策5.23と、CSPMによる継続的な監視についてお話ししました。

クラウドの利用は便利だけど、自分たちの「部屋の鍵」をしっかり管理する責任がある（管理策5.23）。
攻撃者は私たちの「うっかりミス（設定ミス）」を狙っている。
人間の目だけで防ぐのは限界なので、CSPMなどのツールを活用して自動で監視・検知する仕組みを取り入れる。
IaCのコードや静的解析ツールを使って、開発の初期段階からセキュリティを意識する。

セキュリティ対策は、一朝一夕で完璧なものができるわけではありません。最初は難しく感じるかもしれませんが、「まずは不要な公開設定がないかツールでスキャンしてみる」「パスワードの管理を見直してみる」といった小さな一歩の積み重ねが、組織全体を強固な要塞へと変えていきます。

焦らず、一歩ずつ、安全で快適なクラウドライフを作っていきましょう！それではまた次回の記事でお会いしましょう。