【入門編】マルチクラウド環境における一貫したネットワークセキュリティポリシー – インフラ・ネットワーク & クラウドセキュリティ防御ガイド

こんにちは！インフラやセキュリティの世界へようこそ。
セキュリティの世界へ足を踏み入れたばかりの頃は、専門用語ばかりで「何から手をつければいいんだろう……」と不安になりますよね。でも、大丈夫です。一歩ずつ、身近な例えから紐解いていけば、必ず理解できるようになりますよ。

今回は、AWSやAzure、Google Cloudといった複数のクラウドをまたいでシステムを動かすときの「ネットワークの守り方」についてお話しします。

—

1. 家の鍵に例える「ネットワークセキュリティ」の基本

突然ですが、みなさんのご自宅の防犯を想像してみてください。
頑丈な玄関の鍵を閉めますよね。では、もし「裏口の鍵を締め忘れたらどうなるでしょうか？」あるいは「一戸建ての1階はピカピカの防犯ガラスなのに、2階の窓が全開だったら？」……考えただけでもゾッとしますよね。

クラウドの世界もこれとまったく同じです。
「AWS（Amazon Web Services）のサーバーはすごく厳重に守っているけれど、同じシステムで使うAzure（Microsoft Azure）側のデータベースの扉が開きっぱなしだった！」なんてことになったら、泥棒（サイバー攻撃者）は当然、その開いている隙間から侵入してきます。

マルチクラウド（複数のクラウドを組み合わせて使うこと）環境において一番怖いのは、「クラウドごとに防犯のルールがバラバラで、どこかに必ず『うっかり開けっぱなしの扉』ができてしまうこと」なんです。

2. なぜ「手作業」のセキュリティ設定は失敗するのか？

新人エンジニアの頃や、開発に夢中になっているときは、どうしてもクラウドの管理画面（コンソール）をマウスでポチポチと操作して、ファイアウォール（セキュリティグループ）の設定をしがちです。

でも、これが落とし穴なんです。

AWSの設定画面： 「よし、このサーバーへの通信を許可しよう！」（ポチポチ）
Azureの設定画面： 「こっちのサーバーも同じように……あれ、さっきAWSで設定したポート番号、いくつだっけ？」

人間の記憶は曖昧ですし、人間は疲れるとミスをします。結果として、「片方のクラウドではちゃんと鍵をかけたのに、もう片方では忘れていた」というヒューマンエラーが起きてしまいます。
これが、攻撃者に狙われる最大の盲点になります。

3. 解決策：セキュリティを「コード（設計図）」として書く（IaC）

じゃあ、どうすればいいのでしょうか？
そこで登場するのが、今回のテーマである IaC（Infrastructure as Code：インフラストラクチャー・アス・コード） です。

難しそうな名前ですが、要するに「インフラの設定を、すべてテキストのプログラム（設計図）として書いちゃおう！」というアプローチです。今回は代表的なツールである Terraform を例に見てみましょう。

「AWSでもAzureでも、データベースにアクセスできるのは会社のオフィスからだけ！」というルールを、プログラムという共通の設計図で記述してしまうのです。

Terraformのコード例（AWSとAzureの共通セキュリティポリシー）

それでは実際に、Terraformを使って「特定のIPアドレスからしかアクセスできないようにする」安全な壁（セキュリティグループ）のコードを見てみましょう。日本語のコメントを丁寧に書いているので、何をしているのか雰囲気を掴んでみてくださいね。

# ==========================================
# 1. AWS側のセキュリティグループ設定
# ==========================================
resource "aws_security_group" "my_app_aws" {
  name        ="app-server-sg-aws"
  description = "AWS上のアプリサーバーを守るためのセキュリティグループ"

  # 許可する通信のルール（インバウンドルール）
  ingress {
    description = "会社からの安全なアクセスのみを許可"
    from_port   = 443 # データのやり取りに使う「部屋番号（ポート）」のようなもの
    to_port     = 443
    protocol    = "tcp"
    # ここに「会社のIPアドレス」を指定します（例としてダミーのIPを入れています）
    cidr_blocks = ["203.0.113.50/32"] 
  }

  # 外への通信はすべて許可する（安全のため）
  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

# ==========================================
# 2. Azure側のセキュリティグループ設定
# ==========================================
resource "azurerm_network_security_group" "my_app_azure" {
  name                ="app-server-sg-azure"
  location            = "japaneast"
  resource_group_name = "my-security-resources"

  # AWSと同じポリシー（ルール）をAzure側にも全く同じように適用します
  security_rule {
    name                       = "AllowOfficeOnly"
    priority                   = 100
    direction                  = "Inbound"
    access                     = "Allow"
    protocol                   = "Tcp"
    source_port_range          = "*"
    destination_port_range     = "443"
    # AWSと同じ会社のIPアドレスをここにも設定！これでルールにブレがなくなります
    source_address_prefix      = "203.0.113.50/32"
    destination_address_prefix = "*"
  }
}

このようにコードとして管理しておけば、「AWSの設定は変えたけど、Azureを直すのを忘れた！」といううっかりミスを防ぐことができます。なぜなら、この設計図をもとに両方のクラウドを一括でアップデートできるからです。

4. 現場のプロからのアドバイス：セキュリティは「みんなの共通言語」

私たちが現場でインフラを構築するとき、セキュリティは一部の専門家だけがこっそりやるものではありません。開発者も、インフラ担当者も、みんなが同じ「コード（設計図）」を見て、「ここに隙間はないか？」を確認し合うのが現代のスタイルです。

最初はコードの書き方に戸惑うかもしれませんが、心配いりません。
「我が家の鍵は、家族全員で同じルールを守ってしっかりかける」のと同じように、チーム全員でセキュリティの設計図を共有し、育てていけばいいのです。

一歩ずつ、安全で堅牢なシステム作りを楽しんでいきましょう！