【入門編】 GCP組織ポリシー(Organization Policy)によるリソースの制限と禁止事項の強制 – インフラ・ネットワーク & クラウドセキュリティ防御ガイド

こんにちは!インフラやクラウドのセキュリティの世界へようこそ。
初めてクラウドを触るとき、「ボタンひとつでサーバーが作れてすごい!」「世界中のどこからでもアクセスできて便利だな〜」とワクワクしますよね。

でも、ちょっと待ってください。その便利さの裏側には、「うっかりミスで世界中に会社のデータを公開してしまう」というリスクが常に隣り合わせにあります。

今回は、Google Cloud(GCP)の「組織ポリシー(Organization Policy)」という機能を使って、そうしたヒューマンエラーやセキュリティの落とし穴をガッチリ防ぐ方法を、身近な防犯にたとえながら優しく紐解いていきます。

難しそうに見えるセキュリティ用語も、一歩ずつ一緒に見ていけば大丈夫ですよ!それでは、さっそくスタートしましょう。

—

1. なぜ「うっかり」は起きるのか? 家の鍵にたとえて考えてみる

想像してみてください。あなたは新しく大きなお家の管理人になりました。
このお家には、たくさんの部屋(=クラウド上のサーバー)や、外につながるドア(=ネットワーク)があります。

信頼できる家族(=開発メンバー)だけなら良いのですが、もし新人が入ってきたとき、あるいは夜中に眠い目をこすりながら作業しているとき、こんなミスが起きるかもしれません。

  • 「とりあえずすぐ動かしたいから」と、鍵のかかっていない玄関のドア(=世界中に公開されたIPアドレス)をポーンと作ってしまう。
  • 会社で禁止されているはずの海外の物置(=セキュリティ基準を満たさない特定リージョン)に、大事な金庫を置いてしまう。

人間は誰しもミスをします。「気をつけてね」と言葉で注意するだけでは、いつか必ずポカをやらかしてしまうものなんです。

だからこそ、「人間の気合に頼るな、仕組みで強制しろ」というのが、私たちセキュリティエンジニアの鉄則です。GCPの組織ポリシーは、まさに「どんなにうっかり屋さんが操作しても、危険な鍵を開けられないようにする自動ロックシステム」なんです。

—

2. GCP組織ポリシーで防ぐべき「やってはいけない」2大ポイント

現場で特にやらかしがちな、そして攻撃者に一番狙われやすいポイントがこの2つです。

1. 勝手に外の世界と繋がる「公開IP(外部IP)」を持たせること
2. 会社のポリシーで許可されていない遠くの国(リージョン)でサーバーを立てること

攻撃者は、開発者がうっかり付けてしまった「誰でもアクセスできる公開IP」をボットを使って24時間体制で探しています。見つかった瞬間、パスワード総当たり攻撃や脆弱性を突いた乗っ取りが始まります。

これを防ぐために、組織ポリシーを使って「そもそも外部IPの付与を禁止する」「特定のリージョン以外ではリソースを作らせない」というルールを、クラウド全体(組織のルート)にガツンと適用しちゃいましょう。

—

3. 実践!組織ポリシーを設定してみよう

それでは、実際にGCPで組織ポリシーを設定するコード(設定ファイル)を見ていきましょう。
今回は、Terraformというインフラ管理ツールを使って、「特定のリージョン(例: asia-northeast1=東京)以外でのリソース作成を禁止する」ポリシーをコード化してみます。

難しいコマンドは覚えなくて大丈夫です。「こういう風に書くと、クラウド全体を守るルールになるんだな」という雰囲気を感じ取ってみてくださいね。

# GCPの組織全体(Organization)に対してポリシーを適用する設定です
resource "google_org_policy_policy" "restrict_regions" {
  name   = "organizations/123456789012/policies/gcp.resourceLocations"
  parent = "organizations/123456789012"

  spec {
    # ルールを強制(Enforce)する設定です。
    # 「ルールを破るような操作は、エラーにして絶対に受け付けない!」という強い意志を表します。
    reset = false

    rules {
      deny_all = "FALSE"
      
      # 許可する場所(ロケーション)をリスト化します
      # ここでは「日本の東京リージョン(asia-northeast1)」だけを許可しています。
      values {
        allowed_values = [
          "in:asia-northeast1-locations", # 東京リージョンとその周辺を含みます
        ]
      }
    }
  }
}

このように設定しておくと、もし別の開発者が「ちょっとオーストラリアのサーバーでテストしよっと」と操作しても、GCPが自動的に「おっと、そこは組織のルールで禁止されていますよ!」とピシャリと跳ね返してくれます。

—

4. もう一つの定番:「外部IPの禁止」ポリシー

次は、先ほどもお話しした「うっかり公開IP(外部IP)を付けちゃう事故」を防ぐポリシーです。

実務では、内部で使うデータベースやバッチ処理用のサーバーに、インターネットからアクセスできるIPがついてはいけません。これも組織ポリシーでバッチリ制限できます。

# 仮想マシン(Compute Engine)に外部IPを割り当てることを禁止するポリシー
resource "google_org_policy_policy" "disable_external_ip" {
  name   = "organizations/123456789012/policies/compute.vmExternalIpAccess"
  parent = "organizations/123456789012"

  spec {
    rules {
      # 外部IPのアクセスを完全に拒否する(Enforce = true)
      enforce = "TRUE"
    }
  }
}

この設定を入れておけば、万が一、開発者がコンソール画面で「外部IPを付与する」というボタンを押しそうになっても、エラーが出てポチれなくなります。
「えっ、私の設定間違ってる?」と焦るかもしれませんが、これが大正解。事故を未然に防げた証拠です!

—

5. 現場のセキュリティ担当から新人のあなたへ

クラウドのセキュリティ設定は、最初は「なんだか縛りプレイが多くて窮屈だな…」と感じるかもしれません。
「自由にいろんなリージョンを試したいのに!」とか「パッと外部IPをつけてテストしたいのに!」と思うこともあるでしょう。

ですが、思い出してください。セキュリティの目的は、あなたの自由を奪うことではありません。
「あなたや、あなたのチームメイトが、夜も安心してぐっすり眠れる環境を作るため」に、こうしたガードレールが用意されているのです。

攻撃者はたった一つの「うっかり」を何ヶ月も待ち構えています。だからこそ、人間の注意力に頼るのではなく、今回紹介したGCPの組織ポリシーのような「仕組みの防犯」を味方につけて、強固で安全なインフラを一緒に育てていきましょう!

一歩ずつ、確実に知識を身につけていけば、あなたも頼れるセキュリティ・エンジニアに必ずなれますよ。応援しています!

コメント

タイトルとURLをコピーしました