【入門編】セキュリティグループの不備による攻撃対象領域の拡大 – オフェンシブセキュリティ & リバースエンジニアリング防御ガイド

こんにちは！クラウドでのインフラ構築やアプリ開発、毎日お疲れ様です。

突然ですが、皆さんはご自身の家を出るとき、玄関の鍵をしっかり閉めて出かけますよね。「まあ、うちの近所は平和だから鍵を開けっぱなしでも大丈夫か！」なんて思う人は、現代ではあまりいないはずです。泥棒からすれば、鍵の開いている家は「どうぞお入りください」と言われているようなものですからね。

実はこれ、私たちがクラウド（AWSやAzureなど）で作るサーバーの世界でもまったく同じことが言えるんです。今回は、クラウドの「玄関の鍵」にあたるセキュリティグループの不備が引き起こすリスクと、その対策について、身近な例えを交えながら優しく紐解いていきたいと思います。

一歩ずつ一緒に学んでいきましょう！

—

1. クラウドの「玄関の鍵」！セキュリティグループとは？

クラウド上にサーバー（仮想マシン）を立てたとき、私たちはそのサーバーを守るために「セキュリティグループ」という仮想的な防火壁を設定します。

これは、いわば「サーバー専用の頑丈な門番」のようなものです。
「この門番さん、誰を通せばいいの？」というルール（規則）を私たちが教えてあげることで、怪しい侵入者を追い返し、信頼できる通信だけを通すように働いてくれます。

最も危険な設定「0.0.0.0/0」の正体

さて、ここでセキュリティ設定において最大のタブーとされる設定が登場します。それが、接続を許可する送信元IPアドレスに指定する 0.0.0.0/0 という値です。

この 0.0.0.0/0 とは、ネットワークの世界で「全世界のすべての人」「インターネット上のありとあらゆるIPアドレス」を意味します。

これを家の防犯に例えるなら、「我が家の玄関のドアを撤去して、誰でもいつでもリビングに直行できる状態にする」ようなものです。想像しただけでも冷や汗が出てきますよね……！

—

2. なぜ危ないの？SSH/RDP開放が招くブルートフォース攻撃

では、この「玄関を開けっぱなしにした状態（0.0.0.0/0 への開放）」で、特に気をつければいけないのが SSH（Linuxサーバーの遠隔操作用） や RDP（Windowsサーバーの遠隔操作用） のポートを開けっぱなしにしてしまうことです。

攻撃者（サイバー犯罪者や自動化されたボット）は、世界中のインターネットを常にスキャンし、こうした「鍵の開いているサーバー」を血眼になって探しています。

ブルートフォース攻撃（総当たり攻撃）の恐怖

もし、SSH（ポート22）やRDP（ポート3389）が 0.0.0.0/0 に対して開放されていると、攻撃者から以下のような攻撃をダイレクトに受けることになります。

1. ドアのノックが止まらない： 攻撃者のボットが、1秒間に何百回、何千回というペースで「パスワードは何かな？」とログイン試行（ブルートフォース攻撃）を繰り返します。
2. いつか破られる： もしパスワードが「password123」や「admin」といった簡単なものだったり、文字数が少なかったりすると、あっという間に突破されてしまいます。
3. 乗っ取り完了： サーバーの管理者権限が奪われ、勝手に仮想通貨のマイニング（採掘）に使われたり、他の企業を攻撃するための踏み台にされてしまったりします。

「まさか自分のサーバーに限って狙われないだろう」と思っていませんか？ネット上のボットは寝る間も惜しんで数分おきに全IPを巡回しています。鍵を開けた瞬間から、すでにあなたのサーバーは標的なのです。

—

3. では、どう守ればいいの？安全なアクセス制御の基本

「じゃあ、どうやってサーバーを管理すればいいの？」と不安になりますよね。安心してください、守り方はとてもシンプルです。

基本の防衛策

IPアドレスを絞る（ホワイトリスト方式）：

社内オフィスや自宅など、アクセスして良い「自分のIPアドレス（例: 203.0.113.50/32）」からだけ通信を許可します。これなら世界中の他の人からはドアが見えなくなります。

踏み台サーバー（バステションホスト）を使う：

どうしても外部からアクセスする必要がある場合は、直接目的のサーバーにつなぐのではなく、厳重に守られた「専用の検問所（踏み台）」を経由するようにします。

パスワード認証をやめて鍵認証にする：

破られやすい「合言葉（パスワード）」ではなく、本人しか持てない「特別な鍵ファイル（SSH公開鍵認証）」を使います。

—

4. 人間のミスを防ぐ！IaC（インフラコード）を用いた自動監査

「気をつけます！」と言いつつも、人間はうっかりミスをしてしまう生き物です。手動でポチポチとクラウドの設定をしていると、急いでいるときに「まあ、一時的にテストだから 0.0.0.0/0 にしておこう」と設定し、そのまま本番公開してしまう事故が後を絶ちません。

そこで登場するのが、インフラをコードで管理する IaC（Infrastructure as Code） と、その自動監査です。

Terraformというツールを使って、「うっかり危険な設定を書いたら、エラーで弾く」仕組みをコードレベルで組み込んでみましょう。

安全なセキュリティグループを書くためのコード例（Terraform）

以下は、AWSでSSHポートを「特定の安全なIPアドレスからのみ」許可するTerraformのサンプルコードです。日本語のコメントを丁寧に書いているので、ぜひ参考にしてみてください。

# セキュリティグループの定義
resource "aws_security_group" "secure_server_sg" {
  name        = "secure-server-sg"
  description = "Webサーバー用の安全なセキュリティグループ"
  vpc_id      = aws_vpc.main.id

  # 【重要】SSH（ポート22）のインバウンドルール
  ingress {
    description = "社内ネットワークからの安全なSSH接続のみを許可"
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    
    # 悪い例: 0.0.0.0/0 （全世界開放）は絶対に書かない！
    # 良い例: 自社オフィスの固定IPアドレス（例として 203.0.113.50）だけを指定する
    cidr_blocks = ["203.0.113.50/32"] 
  }

  # アウトバウンド（外への通信）は一旦すべて許可する設定例
  egress {
    description = "外への全通信を許可"
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

  tags = {
    Name = "SecureServerSG"
  }
}

このように、コードを書く段階で 0.0.0.0/0 を排除し、誰が見ても「どこから許可されているか」が分かるようにコメントや明確なIPレンジを記載することが、インフラ運用の第一歩になります。

さらに、CI/CDパイプライン（GitHub Actionsなど）の中で tfsec や Checkov といったセキュリティ静的解析ツールを走らせ、「もしコード内に 0.0.0.0/0 と 22（または 3389）の組み合わせがあったら、デプロイ（本番反映）を自動でブロックする」という仕組みを作っておけば、ヒューマンエラーを完全に防ぐことができます。

—

えらい長旅お疲れ様でした！
クラウドの世界はとても便利で自由度が高い反面、設定を一つ間違えると世界中から丸見えになってしまう怖さがあります。

でも、怖がる必要はありません。
「家の鍵をしっかり閉める」のと同じように、
1. 不要なポートを開けない
2. 開けるときは必ず信頼できるIPだけに絞る (0.0.0.0/0 を使わない)
3. 人間だけに頼らず、仕組み（コードや自動監査）でミスを防ぐ

この基本をしっかり押さえていけば、安全で快適なクラウドライフを楽しむことができます。一歩ずつ、確実にセキュアなインフラ構築のスキルを身につけていきましょう！