2026年7月5日

クラウドセキュリティのベストプラクティス

サーバーセキュリティ・SSL

はじめに

クラウド環境は便利な反面、設定一つの誤りで全世界にデータが公開されてしまうリスクと隣り合わせです。S3バケットの公開設定ミス、長期未ローテーションのアクセスキー、過剰なIAM権限などによるインシデントは毎月のように報道されています。

クラウドセキュリティはオンプレと異なり「共有責任モデル」に基づきます。インフラ層はクラウド事業者、設定や運用は利用者の責任という線引きを理解した上で、IAM・ネットワーク・暗号化・監査の4つの軸で防御を組み立てるのが王道です。

本記事ではAWSを主な例としつつ、どのクラウドにも共通する原則と、明日から実装できる具体的なコマンド・設定をまとめます。

症状・背景

S3バケットの誤公開で機密情報が外部から閲覧可能になっていた
退職者のIAMアクセスキーが無効化されないまま残存していた
セキュリティグループで0.0.0.0/0のSSH許可が放置されていた
監査ログ(CloudTrail)が一部リージョンでしか有効化されていなかった

手順・設定方法

ステップ1: ルートアカウントの保護とIAM設計

最も強い権限を持つルートを物理的に隔離します。

# ルートアカウントでMFAを有効化(コンソール操作)
# AWS CLIではIAMユーザーにMFAを必須化するポリシーを適用
aws iam create-user --user-name admin-user
aws iam attach-user-policy --user-name admin-user \
  --policy-arn arn:aws:iam::aws:policy/AdministratorAccess
# アクセスキー作成
aws iam create-access-key --user-name admin-user
# パスワードポリシーを強化
aws iam update-account-password-policy \
  --minimum-password-length 14 --require-symbols --require-numbers \
  --require-uppercase-characters --require-lowercase-characters

ステップ2: 最小権限の原則とアクセスキー監査

不要な権限とキーを定期的に棚卸しします。

# 過去90日未使用のIAMキーを抽出
aws iam list-users --query 'Users[*].UserName' --output text | \
  xargs -n1 aws iam list-access-keys --user-name
# Access AnalyzerでS3バケットの外部公開を検出
aws accessanalyzer create-analyzer --analyzer-name org-analyzer --type ACCOUNT
# 過剰権限のチェック(IAM Access Advisor)
aws iam generate-service-last-accessed-details \
  --arn arn:aws:iam::123456789012:user/admin-user
# 結果ID取得後にdetails取得
aws iam get-service-last-accessed-details --job-id <JOBID>

ステップ3: ネットワーク境界の堅牢化

Security GroupとVPCでアタックサーフェスを最小化します。

# 0.0.0.0/0のSSH許可ルールを検出
aws ec2 describe-security-groups \
  --query "SecurityGroups[?IpPermissions[?ToPort==\`22\` && IpRanges[?CidrIp=='0.0.0.0/0']]].GroupId" \
  --output text
# 不要な0.0.0.0/0 ルールを削除
aws ec2 revoke-security-group-ingress \
  --group-id sg-0123abcd --protocol tcp --port 22 --cidr 0.0.0.0/0
# VPCフローログを有効化
aws ec2 create-flow-logs --resource-type VPC --resource-ids vpc-xxxx \
  --traffic-type ALL --log-destination-type cloud-watch-logs \
  --log-group-name /aws/vpc/flowlogs

ステップ4: 監査・暗号化・GuardDutyを有効化

全リージョンで脅威検知と監査ログを常時取得します。

# CloudTrailを全リージョン+組織トレイルで有効化
aws cloudtrail create-trail --name org-trail \
  --s3-bucket-name audit-logs-bucket --is-multi-region-trail --is-organization-trail
aws cloudtrail start-logging --name org-trail
# GuardDutyを有効化(脅威検知)
aws guardduty create-detector --enable
# S3バケットのデフォルト暗号化を有効化
aws s3api put-bucket-encryption --bucket my-bucket \
  --server-side-encryption-configuration \
  '{"Rules":[{"ApplyServerSideEncryptionByDefault":{"SSEAlgorithm":"AES256"}}]}'
# Config Rulesでコンプライアンス自動チェック
aws configservice put-config-rule --config-rule file://s3-bucket-public-prohibited.json

注意事項

ルートアカウントでの日常運用は絶対に行わず、IAMユーザー+MFAで作業する
アクセスキーはCI/CDではなくIAMロールやOIDC連携で発行不要にする
セキュリティグループの変更は影響範囲が広いため、describeで事前確認する
GuardDuty/Config/CloudTrailは全リージョンで有効化(未使用リージョンに侵入される事例多数)

まとめ

1. MFA必須化 とルート保管が大前提

2. 最小権限の原則 をIAM Access Advisorで検証

3. VPC + Security Group で境界防御

4. CloudTrail/GuardDuty/Config の三点セットで監査・検知

5. 暗号化のデフォルト化 でうっかり平文流出を防止

Post Views: 2