ELBにおけるアクセスログの有効化手順

このブログシリーズ 「クラウドセキュリティ 実践集」 では、一般的なセキュリティ課題を取り上げ、「なぜ危険なのか?」 というリスクの解説から、「どうやって直すのか?」 という具体的な修復手順(コンソール、AWS CLI、Terraformなど)まで、分かりやすく解説します。
今回は、Elastic Load Balancing (ELBv2) のロードバランサーでアクセスログが有効になっていない状態について、そのリスクと対策を解説します。

リスク
Elastic Load Balancing (ELBv2) は、Application Load Balancer (ALB) および Network Load Balancer (NLB) を含む、AWSの次世代ロードバランシングサービスです。これらのロードバランサーは、アプリケーションへのトラフィックを効率的に分散し、高可用性とスケーラビリティを提供します。しかし、ELBv2のアクセスログが有効になっていない場合、以下のような重大なセキュリティおよび運用上のリスクを引き起こします。
- セキュリティインシデント検知の遅延: ELBv2のアクセスログは、潜在的な攻撃(例: Webアプリケーション攻撃、DDoS攻撃の兆候)、悪意のある活動(例: ポートスキャン、異常なリクエストパターン)、またはバックエンドリソースの不正使用を検出するための重要な情報源です。ログがなければ、これらの異常な活動を早期に検知することが極めて困難になります。
- フォレンジック調査の困難さ: セキュリティインシデントが発生した場合、ELBv2のアクセスログは、攻撃がロードバランサーをどのように通過したか、どのリソースが影響を受けたか、どのIPアドレスが関与していたかなどを特定するための決定的な証拠となります。ログがなければ、詳細なフォレンジック調査を実行できず、根本原因の特定や再発防止策の立案が難しくなります。
- アプリケーションパフォーマンスの問題特定不可: アクセスログには、リクエストのレイテンシー、HTTPステータスコード、リクエストパスなどの情報が含まれます。これらの情報は、アプリケーションのパフォーマンスボトルネック、エラーの傾向、ユーザーエクスペリエンスの問題を特定し、トラブルシューティングを行う上で不可欠です。ログがなければ、これらの運用上の問題を効率的に解決できません。
- トラフィックパターンの分析不足: ELBv2のアクセスログは、ユーザーがアプリケーションをどのように利用しているか、どのページが頻繁にアクセスされているか、どの地域からのトラフィックが多いかなど、貴重なビジネスインテリジェンスを提供します。ログがなければ、これらの情報を活用したマーケティング戦略やサービス改善の機会を逃すことになります。
対策
ELBv2のアクセスログを有効化することは、セキュリティ監視、トラブルシューティング、およびアプリケーション分析能力を大幅に向上させるための非常に重要なベストプラクティスです。
- ログの保存先をS3バケットに設定: ELBv2のアクセスログは、指定したAmazon S3バケットに送信されます。ログの保存には、長期保存、コスト効率、および大規模なデータ分析に適したS3バケットを使用します。
- 適切なバケットポリシーの設定: ELBv2サービスがログをS3バケットに書き込むための適切なS3バケットポリシーを設定する必要があります。このポリシーは、ELBログ配信サービスプリンシパル(
elb.amazonaws.com
)からのs3:PutObject
アクションを許可するように設定します。 - ログの保存期間とライフサイクル: ログを保存するS3バケットには、組織のコンプライアンス要件や分析要件に合わせてS3ライフサイクルポリシーを設定し、ログの保持期間を管理します。不要になったログを自動的に削除したり、Glacierなどの低コストストレージにアーカイブしたりすることで、コストを最適化できます。
- ログの分析と監視: ELBv2アクセスログを収集したら、それを活用してセキュリティ監視と運用効率を向上させます。
- Amazon AthenaとAmazon QuickSight: S3に保存されたログをSQLクエリで分析し、トラフィックパターン、エラー、潜在的な攻撃を可視化できます。
- AWS Security Hub / GuardDuty: ELBv2ログと連携して、脅威検出とセキュリティ状態の監視を強化できます。
- CloudWatch Events / Lambda: S3バケットへのログファイルの書き込みイベントをトリガーとして、カスタムのセキュリティチェックやアラート通知を自動化できます。
修復方法
AWSコンソールでの修復手順
AWSコンソールを使用して、ELBのアクセスログを有効にします。
前提:
- アクセスログを有効にしたいELB(ALB、NLB、CLBいずれか)が存在すること。
- アクセスログの保存先となるS3バケットが既に存在すること。
- EC2サービスへ移動: AWSコンソールにログインし、Amazon EC2 サービスを開きます。
- ロードバランサーの選択: 左側のナビゲーションペインで「ロードバランシング」の下にある「ロードバランサー」を選択します。
- 対象のロードバランサーの選択: アクセスログを有効にしたいロードバランサー(ALB, NLB, または CLB)を選択します。
- 属性/説明タブへ移動: ロードバランサーの詳細ページで、「属性」タブを見つけ、「編集」をクリックします。
- アクセスログの設定:
- 「アクセスログ」をオンにします。
- アクセスログを保存するS3バケットを選択します。
- プレフィックス (オプション): 必要に応じて、ログファイルの名前の前に付加されるプレフィックス(例:
my-application-logs/
)を指定できます。これにより、ログファイルを整理しやすくなります。
- 変更を保存: 設定を確認し、「変更内容の保存」をクリックします。

これで、ELBv2へのリクエストに関するアクセスログが、指定したS3バケットに記録されるようになります。ログの配信には数分から数時間かかる場合があります。
Terraformでの修復手順
TerraformでELBv2のアクセスログを有効にするには、aws_lb
リソースの access_logs
ブロックを既存の aws_lb
リソースに追加または更新します。
# (例) ELBv2アクセスログを保存するためのS3バケット
resource "aws_s3_bucket" "elb_v2_access_log_bucket" {
bucket = "my-elb-v2-access-logs-unique-20250706" # グローバルで一意の名前に変更
force_destroy = true # テスト用。本番環境ではfalseを推奨
tags = {
Name = "ELBv2AccessLogBucket"
}
}
# S3バケットポリシー (ELBv2サービスがバケットにログを書き込めるようにする)
resource "aws_s3_bucket_policy" "elb_v2_access_log_bucket_policy" {
bucket = aws_s3_bucket.elb_v2_access_log_bucket.id
policy = jsonencode({
Version = "2012-10-17",
Statement = [
{
Sid = "AllowELBv2Logs"
Effect = "Allow"
Principal = {
AWS = "arn:aws:iam::${data.aws_caller_identity.current.account_id}:root" # ALB/NLBはアカウントID rootプリンシパルを使用
},
Action = "s3:PutObject",
Resource = "${aws_s3_bucket.elb_v2_access_log_bucket.arn}/AWSLogs/${data.aws_caller_identity.current.account_id}/*",
Condition = {
StringEquals = {
"s3:x-amz-acl" = "bucket-owner-full-control"
}
}
},
{
Sid = "S3BucketAclCheck"
Effect = "Allow"
Principal = {
AWS = "arn:aws:iam::${data.aws_caller_identity.current.account_id}:root" # ALB/NLBはアカウントID rootプリンシパルを使用
},
Action = "s3:GetBucketAcl",
Resource = aws_s3_bucket.elb_v2_access_log_bucket.arn
}
]
})
}
# 現在のAWSアカウント情報を取得
data "aws_caller_identity" "current" {}
# (例) Application Load Balancer (ALB) の定義
resource "aws_lb" "my_alb_v2" {
name = "my-secure-alb-v2"
internal = false
load_balancer_type = "application"
security_groups = ["sg-0abcdef1234567890"] # あなたのセキュリティグループIDに置き換え
subnets = ["subnet-0abcdef1234567890", "subnet-0fedcba9876543210"] # あなたのサブネットIDに置き換え
# アクセスログ設定
access_logs {
bucket = aws_s3_bucket.elb_v2_access_log_bucket.id
prefix = "alb-v2-logs" # ログファイルに付加されるプレフィックス
enabled = true
}
tags = {
Name = "MyALBv2"
}
}
# (オプション) Network Load Balancer (NLB) の定義例
/*
resource "aws_lb" "my_nlb_v2" {
name = "my-secure-nlb-v2"
internal = false
load_balancer_type = "network"
subnets = ["subnet-0abcdef1234567890", "subnet-0fedcba9876543210"] # あなたのサブネットIDに置き換え
# アクセスログ設定
access_logs {
bucket = aws_s3_bucket.elb_v2_access_log_bucket.id
prefix = "nlb-v2-logs" # ログファイルに付加されるプレフィックス
enabled = true
}
tags = {
Name = "MyNLBv2"
}
}
*/
上記のTerraformコードでは、aws_lb
リソースの access_logs
ブロックを設定することで、ELBv2(ALBまたはNLB)のアクセスログを有効にしています。
bucket
: アクセスログの保存先となるS3バケットのIDを指定します。prefix
: ログファイルに付加されるプレフィックスを設定します。enabled = true
: アクセスログを有効にします。
S3バケットのポリシー (aws_s3_bucket_policy
) は、ELBv2サービスがS3バケットにログを書き込めるように、該当リージョンのELBサービスアカウントID(またはrootアカウントARN)からのs3:PutObject
権限を許可する必要があります。
my-elb-v2-access-logs-unique-20250706
、sg-0abcdef1234567890
、subnet-0abcdef1234567890
などのプレースホルダーは、実際の環境に合わせて修正してください。
最後に
この記事では、ELBv2のアクセスログを有効にすることの重要性について解説しました。アクセスログは、セキュリティ監査、トラブルシューティング、アプリケーションのパフォーマンス分析に不可欠な情報源であり、これを有効にすることは、ELBv2を介してアプリケーションを運用する上での基本的なセキュリティ対策です。
貴社のELBv2ロードバランサーでは、アクセスログが適切に有効になっていますか?この機会にぜひ設定を確認・強化してみてください。
こちらの内容の検出は弊社が提供するSecurifyのCSPM機能で簡単に検出及び管理する事が可能です。運用が非常にラクに出来る製品になっていますのでぜひ興味がある方はお問い合わせお待ちしております。
最後までお読みいただきありがとうございました。この記事が皆さんの役に立てば幸いです。