境界防御の限界：なぜ「SSH全開放」があなたのキャリアを終わらせるのか
現場でインシデント対応をしていると、いまだに「開発用だから」という理由で、Security Group（SG）のインバウンドルールに 0.0.0.0/0 でポート 22 (SSH) や 3389 (RDP) を開けている環境を散見します。
正直に言おう。それは、「泥棒に玄関の鍵を渡したまま、防犯カメラを設置して安心している」のと同じだ。
攻撃者はあなたのSSHポートを見つけた瞬間、ブルートフォース攻撃や、最近では OpenSSH のゼロデイ脆弱性を突くスキャナーを走らせる。パッチが数日遅れただけで、あなたのインスタンスはクリプトジャッキングの踏み台か、ランサムウェアの拠点に早変わりする。
今日は、そんな「古き悪しき運用」を捨て、現代のクラウドインフラにおける「真のセキュアなアクセス管理」の作法を叩き込む。
—
攻撃者の視点：ポート開放が招く「公開処刑」
攻撃者は nmap や masscan を使い、世界中のIPアドレスに対して数ミリ秒で全ポートスキャンを行う。
# 攻撃者が実行するスキャン例（絶対に真似してはいけない）
nmap -p 22,3389 --open <あなたのAWSのグローバルIP>もしポート 22 が開いていれば、彼らは即座に Hydra や Medusa を使ってログインを試みる。SSH鍵認証にしていたとしても、SSHデーモン自体に脆弱性があれば、認証をバイパスされてルート権限を奪取される。これが「公開処刑」のシナリオだ。
—
解決策：AWS Systems Manager (SSM) Session Manager という「聖域」
SSH/RDPのポートをインターネットに公開する必要は、もはや一切ない。AWSのベストプラクティスは、「SSM Session Manager」の利用だ。
これは、エージェントがインスタンス内で動作し、HTTPS（443番ポート）経由でAWSの管理プレーンと通信する。つまり、インバウンドポートを1つも開けずにリモートアクセスが可能になる。
ステップ1: セキュアなIAMロールの設計
まず、インスタンスに付与するIAMロールを作成する。AmazonSSMManagedInstanceCore ポリシーをアタッチするだけでいい。これだけで、インスタンスはAWSのSSMサービスとセキュアに通信を開始する。
ステップ2: Security Groupを「ゼロ」にする
Security GroupのインバウンドルールからSSH/RDPを削除し、以下のように「インバウンドルールなし」の状態を目指す。
- タイプ: なし（あるいは、必要なアプリケーションポートのみ許可）
- ソース: 0.0.0.0/0 などの広域指定は絶対に禁止
ステップ3: 接続テスト（Terraformでの実装例）
Terraformでインスタンスを作成する際、SSM対応を前提とした構成は以下の通りだ。
# SSM用のIAMポリシーをインスタンスに紐付ける
resource "aws_iam_role" "ssm_role" {
name = "instance-ssm-role"
assume_role_policy = jsonencode({
Version = "2012-10-17"
Statement = [{
Action = "sts:AssumeRole"
Effect = "Allow"
Principal = { Service = "ec2.amazonaws.com" }
}]
})
}
resource "aws_iam_role_policy_attachment" "ssm_attach" {
role = aws_iam_role.ssm_role.name
policy_arn = "arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore"
}
# Security Group: ポート22は開けない！
resource "aws_security_group" "web_sg" {
name = "web-server-sg"
description = "No SSH, only HTTP/HTTPS"
ingress {
from_port = 443
to_port = 443
protocol = "tcp"
cidr_blocks = ["0.0.0.0/0"]
}
}—
なぜこれが「最強」なのか？
1. ポートの隠蔽: インターネットから攻撃可能なエントリーポイントが完全に消滅する。
2. 監査ログの記録: 誰が、いつ、どのコマンドを実行したか、SSMのログ設定を有効にすれば S3 や CloudWatch Logs にすべて記録される。
3. キー管理からの解放: SSH秘密鍵を配布したり、ローテーションしたりする地獄のような運用から解放される。
運用現場でのTips：CLIでの接続
開発者はわざわざSSHクライアントを立ち上げる必要はない。ターミナルから以下のコマンドを打つだけだ。
# インスタンスIDを指定してセッション開始
aws ssm start-session --target i-0123456789abcdef0これだけで、IAM認証を経由したセキュアなシェル環境が手に入る。もし特定のアプリ開発者が特定のディレクトリにアクセスする必要があるなら、IAMポリシーで ssm:SendCommand を制限すればいい。
—
最後に：セキュリティは「設定」ではなく「マインドセット」だ
「利便性のためにSSHを開ける」という妥協は、プロフェッショナルの仕事ではない。セキュリティの設計とは、「最も脆弱な場所をいかに消し去るか」という引き算の芸術だ。
今日からあなたのAWS環境のSecurity Groupを見直し、SSHポート 22 を閉じてほしい。もし、「どうしてもSSHが必要な理由」があるなら、それは設計を見直すべきサインだ。
不明点があれば、いつでもエンジニアチームの相談に乗る。堅牢なシステムを作るのは、我々のプライドだ。健闘を祈る。
コメント