この記事は MICIN Advent Calendar 2025 の 8日目の記事です。
前回は manimoto さんの Google Apps Script で Google ドキュメント操作 逆引きリファレンス でした。
はじめに
こんにちは、横断エンジニアリング部（Cross Functional Engineering,CFE）の黒澤です。
CFEは、MICINのプロダクト共通の要件であるインフラやセキュリティに関する対応を担当しており、日々AWSと格闘しています。
以前からAWS用のSIEMとして使っていたOpenSearchですが、ついにメジャーバージョンアップに踏み切りました。
この記事ではその作業について触れようと思っていたのですが思わぬ落とし穴で切り替えは保留となってしまいました。
ただその作業の中で、AWS Organization環境でのログに関して色々な対応をしたこともあり、ここではLog Archiveアカウントについてまとめます。
OpenSearchをバージョンアップしよう
重い腰をあげた大きなモチベーションは、OpenSearchでも自然言語検索が行えるようになった点です。
通常、OpenSearchを触るにはQuery DSLという言語やGUIでの表示項目操作といったスキルが必要です。
しかし、自然言語検索が利用できるようになったことで操作のハードルが下がり、エラー調査がより効率的に誰でも行えるのではないかと考えました。
また、構築当初はアクセスできる人を絞るためにAWS VPN Client経由での接続としていますが、OpenSearchへの認証をOneLoginと統合したため、VPN自体も不要と考えました。
AmazonQに頑張ってもらった
どうにか新しいOpenSearch環境を構築し、SIEM on Amazon OpenSearch（以下SIEM）が利用できるようになりました。
作業当時の最新バージョン2.19とし、各種ログの取り込みや表示も確認し、いざ切り替えです。
ちなみに2025年12月時点での最新バージョンは3.1となっています。
そして問題が
実は現在のOpenSearch環境はリザーブドインスタンスを契約しており、その契約期間が半年ほど残っていました。
リザーブドインスタンスは特定のリージョン、インスタンスタイプ、OS、テナンシーに対して割引が適用される仕組みです。
そう、契約期間中のリザーブドインスタンスではリージョン切り替えはできないのです。
何とかならないものかと調べてみると、契約したリザーブドインスタンスをマーケットプレイスで販売できるようです！
よし、まずはマーケットプレイスで販売者登録してと・・・アメリカの銀行に口座が必要・・・え？
更に読み進めると、そもそもマーケットプレイスで販売できるのはEC2のみだそうです。
・・・詰みました。
新しいOpenSearchへの切り替えは、現在のリザーブドインスタンス契約を更新するタイミングとなりました。
色々見直した
気を取り直して記事を続けます。
今回のSIEM再構築にあたって幾つか変更を入れています。
- 利用するリージョンをオハイオから東京に変更
- VPCフローログ、GuardDutyなど、取り込めるログを増やす
- SIEM専用のアカウントは廃止し、Log Archiveアカウントに統合する
オハイオから東京に変更
これは遅延対策として実施しています。
MICINが最初にAWSの環境を構築した2015年頃は、色々なサービスの使用がアメリカのリージョンに限定されていたようです。
特に管理系のサービス（ControlTowerやOrganizationなど）を利用したい場合、アメリカのリージョンを指定することが多かったようです。
このため、SIEMの構築もオハイオリージョンを使っています。
更にVPN Clientも利用していたため、通信環境への負荷は高いものと思われます。
少しでも遅延が減ることを期待して行った変更です。
取り込めるログを増やす
これまで取り込んでいたのはCloudTrail、WAF、SecurityHubの3つでしたが、他のログも取り込めるようにしておきたい！
ただ、OpenSearchインスタンスのストレージも無制限ではありません。
そこで、まずはVPCフローログとGuardDutyのログがちゃんと出力される環境を整えます。
ログさえ出力されていれば、SIEMへの取り込みはいつでもできるだろうと考えました。
Log Archiveアカウントに統合する
SIEMの環境だけのために別アカウントを１つ用意するのはコスト的に無駄なのではと考えました。
後述するLog Archiveアカウントの特性上、ここにSIEMの環境を作るのはよろしくなさそうではありますが、様々なログを取り込むSIEMはログの近くにあるのが運用的にも楽だろうと考えました。
Log Archiveの役割
Log Archiveアカウントとは
ここから本題のLog Archiveアカウントに触れていきます。
Log Archiveアカウントは、AWS Control Towerで自動作成される特別なアカウント（Management、Audit、Log Archive）の1つです。
ただし作成される特別なアカウントやOUはControlTowerを有効化した時期によって異なるようです。
MICIN環境では、Audit、Log Archiveの2つのアカウントが特別なアカウントとして作成されています。
Log Archiveアカウントの役割は、複数のAWSアカウントで出力されるログを集中的に、かつ厳格に管理する（削除や変更はもちろん、改ざん不可、検知など）ことを担っています。
ログ管理には以下の技術が推奨されています。
- CloudTrail Log File Integrity Validation (CloudTrailログの改ざん検知)
- S3 Object Lock（WORM） (S3バケットに一度書き込んだら削除・変更不可となる)
- バージョニング（S3バケットへの書き込み履歴を保持）
また、あくまでログの管理に特化したアカウントであることから、本番ワークロードの実行や、分析ツールの実行も避けるのが望ましいとされています。
ログを管理するという特性から、Log Archiveアカウントへのアクセスは非常に限定されています。
MICINでもAWSの全体を管理するSREチームとセキュリティチームのみがアクセス可能なアカウントとなっています。
改めてSIEMをLog Archiveアカウントに作る意味
Log ArchiveアカウントにSIEMを作ることには一長一短があります。
ログの管理アカウントでSIEM関連のリソースを作成、動作させることは前述の通り避けるべきですし、厳密な監査を必要とする企業では、このアカウントで何かを行うことを良しとはされないでしょう。
ただ、コスト以外にも、SIEMをLog Archiveアカウントに構築するメリットはあるように思われます。
SIEMでは、SIEM取り込み用のS3バケットに分析したいログをレプリケーションするだけで、勝手に取り込んでくれます。
同じアカウントに元となるログバケットとSIEM取り込み用のバケットがあることで分析対象の追加や削除作業が容易にできるというメリットがあります。
OpenSearchインスタンスのストレージの関係で、分析対象とするログは時に変更する可能性を考えると、作業が楽になる要素は大歓迎です。
また、SIEMがログの保存先に近いことにより、ログの取り込みや分析のパフォーマンス向上に寄与します。
更に、Log Archiveアカウントはそもそもアクセスできる人が少なく、SIEM環境の保護という点でも安心です。
ログを出力してみる
実際にVPCフローログやGuardDutyのログを出力していきます。
VPCフローログの出力設定
以下はメンバーアカウント側でVPCフローログを出力するためのTerraformコードです。
コードはテンプレート化しており、MICINで作成される全ての環境でVPCフローログの出力が設定されるようにしています。
また、出力項目(log_formatにて定義)は標準のものに加えて、ECS関連の項目も出力するようにしています。
resource "aws_flow_log" "logs" {
log_destination = destination_bucket
log_destination_type = "s3"
traffic_type = "ALL"
vpc_id = var.vpc_id
log_format = <<-EOT
$${version} $${account-id} $${interface-id} $${srcaddr}
$${dstaddr} $${srcport} $${dstport} $${protocol} $${packets} $${bytes}
$${start} $${end} $${action} $${log-status} $${vpc-id} $${subnet-id}
$${instance-id} $${pkt-src-aws-service} $${pkt-dst-aws-service}
$${reject-reason} $${tcp-flags} $${type} $${pkt-srcaddr} $${pkt-dstaddr}
$${region} $${az-id} $${sublocation-type} $${sublocation-id} $${flow-direction}
$${traffic-path} $${ecs-cluster-name} $${ecs-service-name} $${ecs-task-arn} $${ecs-container-id}
EOT
destination_options {
file_format = "parquet"
hive_compatible_partitions = true
per_hour_partition = true
}
tags = {
"Name" = "env-flowlogs"
}
}
GuardDutyのログ出力設定
GuardDutyについては、検出結果のエクスポートオプションを指定することでS3バケットへの出力設定を行います。
（こちらは管理コンソールでの設定箇所を示します）
出力先となるLog Archiveへのバケット作成
各アカウントで出力したログを集約するためにLog Archiveアカウントに集約バケットを作成します。
各メンバーアカウントから集約バケットへのアクセス許可をバケットポリシーに定義するのですが、Log Archiveアカウントではバケットポリシーの変更が禁止されています。
これはOrganizationでLog Archiveが所属するOUにサービスコントロールポリシー（SCP）が適用されており、その中で、S3バケットに対する操作が制限されていることに起因します。
そこで、一時的に緩めのポリシーを設定した作業用OUを作成し、Log Archiveアカウントをそちらに移して作業し、作業後に元のOUに戻すという方法で対応しました。
SCPを変更するという手もありますが、SCPは極力変更しないこととしました。
集約バケットに設定するバケットポリシーは以下のようになります。
VPCフローログを出力するメンバーアカウントは、新規で追加されたり、サービス終了時に削除されたりするため不定期に変更されることが予想されます。
その都度バケットポリシーを変更するのは大変なので、Conditionブロックでaws:SourceOrgIDを指定しています。
これにより、VPCフローログを出力するアカウントが追加・削除されても、同じOrganizationに属するアカウントであればLog Archiveアカウント側は設定変更せずに済みます。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AWSLogDeliveryWrite",
"Effect": "Allow",
"Principal": {
"Service": "delivery.logs.amazonaws.com"
},
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::vpc-flow-logs-bucket/vpc-flow-logs/*",
"Condition": {
"StringEquals": {
"aws:SourceOrgID": "organization_id",
"s3:x-amz-acl": "bucket-owner-full-control"
}
}
},
{
"Sid": "AWSLogDeliveryAclCheck",
"Effect": "Allow",
"Principal": {
"Service": "delivery.logs.amazonaws.com"
},
"Action": "s3:GetBucketAcl",
"Resource": "arn:aws:s3:::vpc-flow-logs-bucket",
"Condition": {
"StringEquals": {
"aws:SourceOrgID": "organization_id"
}
}
}
]
}
Log Archiveへの出力フロー図
最終的に以下のような出力フローになりました。
今回の作業でGuardDuty、VPCフローログをSIEMで確認できるようになります。
ただ全てのアカウントのVPCフローログをSIEMに取り込むと、あっという間にストレージがパンクしてしまいます。
このため本番環境など特定のアカウントのみ、ログをSIEMに取り込む想定です。
また、メンバーアカウントにログを出力しレプリケーションするのではなく、Log Archiveアカウントに直接出力することとしました。
これにより、メンバーアカウントが侵害されてもログが改ざんされることを防止できます。
おわりに
最後までお読みいただきありがとうございました。
普段目立たないLog Archiveアカウントなのですが、実は重要な役割を担っているというお話でした。
MICINでの運用は必ずしもベストプラクティスに沿ったものではないかもしれません。
ただ事業規模やコスト、運用のしやすさなどの条件を鑑みるとベタープラクティスくらいが丁度よいということもありかなと思います。
今回Log Archiveアカウントを見直したことで、出力されていないログを洗い出せたり、ライフサイクル設定を見直したりとリファクタリングポイントが見えてきました。
当初予定していたSIEMの切り替えという目標は果たせていないものの、他の課題が見えたのは思わぬ成果でした。
MICINではメンバーを大募集しています。
「とりあえず話を聞いてみたい」でも大歓迎ですので、お気軽にご応募ください！
Discussion