はじめに

AWSを使っていると、こんな経験はないでしょうか。

離任したメンバーが作ったEC2がいつの間にか動き続けていた
「テスト用」のつもりで作ったRDSがそのまま残っていた
何のために作ったのかわからないリソースが増えていく

タグで管理すれば解決できる話ですが、「タグを付けるルール」はあっても「タグがなければ動かせない仕組み」がない限り、人は必ずミスをしてしまうものだと思います。

AWS OrganizationsのSCPを使えばタグなしリソースの作成を組織レベルで拒否できますが、個人・スタートアップ・小規模チームにはオーバースペックです。

そこで、SCPなしでもタグ管理によるセキュリティガバナンスを実現する TagWatchman を作りました。

なぜ作ったか

タグ管理の問題は単なるコスト管理の話ではありません。

セキュリティ的に見ると、「誰が何のために作ったかわからないリソース」は攻撃者がバックドアとして作ったインスタンスかもしれません。 管理外リソースは：

パッチが当たらない
監査されない
ログが見られない

つまり、「存在を把握できていないこと」自体がリスクです。

既存のOSSツールをいくつか調べましたが、いずれも：

定期スキャン型（数時間遅延がある）
対応サービスがEC2・RDS程度に限定
隔離フェーズがなく、通知か即削除の二択
導入が複雑

という課題がありました。これを解決するものを作ろうと思ったのが出発点です。

アーキテクチャ

Lambda 8関数の役割

Lambda	役割
Detector	CloudTrailイベントからARNを抽出・タグチェック
Isolator	ネットワーク隔離（SG差し替え / ポリシー封鎖）
Notifier	メール通知（検知時・承認依頼時）
Recheck	7日後にタグを再チェック
Restorer	タグが付与されたら隔離解除
Approver	承認URLクリックを処理
Deleter	リソース削除
CloudTrail Guardian	CloudTrailの無効化・削除を監視

工夫したポイント

① 即削除ではなく「隔離→承認→削除」

最初は検知したら即削除する設計を考えましたが、これは運用事故のリスクが高すぎると判断しました。

タグの付け忘れという操作ミスや、CI/CDが自動作成するリソースでタグ付与にラグがあるケースなど、即削除としてしまうとかえって事故発生のリスクがあると考えます。

そこで以下のフローにしました：

検知 → 即時隔離（通信遮断）→ 7日間の猶予
    ↓ この間にタグを付与 → 自動復旧
    ↓ タグなしで7日経過 → 承認メール
    ↓ 人間がクリック → 削除

隔離はするが、削除は人間が判断する。 これが安全なバランスだと考えています。

ただし、一部AWSサービスは、セキュリテイもしくは技術的な観点からネットワーク隔離以外の対応をしています。詳細は③ 対応AWSサービスにて説明します。

② 隔離 = 停止ではなくネットワーク遮断

隔離の方法として「インスタンスのStop」も考えましたが、これも強硬手段すぎると判断しました。RDSはStop後の起動に時間がかかりますし、誤検知のときのダメージが大きいので...

「害を与えられない状態にする」であって「リソースの停止・消去」ではない という思想で、通信遮断（SGの差し替え・バケットポリシーの全拒否）を選びました。

元のSGはタグに保存しているので、タグを付与すれば自動で復旧します。

③ 対応AWSサービス

Resource Groups Tagging APIを使うことで、サービスごとの個別実装なしに全AWSサービスのタグを統一取得できます。

カテゴリ	サービス	隔離方法	復旧方法
コンピューティング	EC2, Lambda, ECS, EKS, Workspaces	SGを全拒否に差し替え / 同時実行数を0に設定	タグ付与で自動復旧
データベース	RDS, DynamoDB, ElastiCache, Redshift	SGを全拒否に差し替え / リソースポリシーで全拒否	タグ付与で自動復旧
ストレージ	S3, ECR	バケット/リポジトリポリシーで全拒否	タグ付与で自動復旧
メッセージング	SQS, SNS, Kinesis	ポリシーで全拒否	タグ付与で自動復旧
分析	OpenSearch	ポリシーで全拒否	タグ付与で自動復旧
分析（通知のみ）	Glue	通知のみ ※1	—
オーケストレーション	Step Functions	リソースポリシーで全拒否	タグ付与で自動復旧
ネットワーク	IGW, NAT Gateway, VPC Peering, ElasticIP	条件付き即時削除 ※2	—
ネットワーク（通知のみ）	VPC	通知のみ ※3	—
認証・認可	IAM Role, IAM User	ポリシー全剥奪 + アクセスキー無効化 ※4	タグ付与でタグ削除（ポリシー再付与は手動）
API	API Gateway	ステージ削除によるエンドポイント無効化	タグ付与で自動復旧
監査	CloudTrail	専用フロー（自動再有効化）	—

👉 リソース別の挙動詳細はこちら

※1 Glueを通知のみにする理由

リソースポリシーがデータカタログ全体に適用されるため、database単位での隔離が不可能

※2 ネットワーク系（条件付き即時削除）の挙動

IGW: アタッチなし → 即時削除 / アタッチあり → 通知のみ
NAT Gateway / VPC Peering: 即時削除
ElasticIP: アタッチなし → 即時解放 / アタッチあり → 通知のみ

※3 VPCを通知のみにする理由

削除すると内部の全リソースの通信が止まる。影響範囲が大きすぎるため自動対応不可

※4 IAMリソースの挙動

ポリシー剥奪・キー無効化は自動で実施
復旧（ポリシー再付与・キー再作成）は人間が手動で対応が必要
メール通知に手動対応が必要な旨を明記

④ CloudTrail Guardianで生命線を守る

TagWatchmanはCloudTrailのイベントを受け取って動いています。つまりCloudTrailが止まるとTagWatchman自体が機能しなくなってしまいます。

攻撃者がバックドアを仕込む際にまずやることのひとつが「ログの無効化」です。これに対応するため、CloudTrailの操作を専用のLambdaで監視しています。

StopLogging  → 自動で再有効化 + 🚨 CRITICAL警告
DeleteTrail  → 🚨 CRITICAL警告（再作成は人間が対応）
UpdateTrail  → ⚠️ WARNING警告
PutEventSelectors → ⚠️ WARNING警告

⑤ 猶予期間はSSMで可変

デフォルト7日ですが、AWS Systems Manager Parameter Storeで変更できます。再デプロイ不要で簡単に実施できます。

タグバリデーションの設計

単純に「タグキーが存在するか」だけでなく、値のバリデーションも実装しました。

Env は許可値リストと照合
Project は前方一致で柔軟に対応
Owned は空文字のみNG（値は自由、チーム名を推奨）
設定はSSM Parameter Storeから変更でき、再デプロイ不要で即時反映されます。

詳細な設定方法は購入者向けのドキュメントにて記載しています。

実際に動かしてみた

タグなしでS3バケットを作成したところ、約1〜2分後に以下のメールが届きました。

リソースのARN
操作の種類（CreateBucket）
実行者のIAMロール
不足しているタグ
自動で隔離（通信遮断）した旨
7日後に削除承認メールが届く旨

実環境でリアルタイムに動作することを確認できました。

導入方法

現在 v1.0.0 をリリース準備中です。

近日中に販売を開始予定です。
リリース通知を受け取りたい方は ⭐ Star をお願いします！

👉 https://github.com/takada-neko/tag-watchman

AWS利用料

TagWatchman自体の追加コストはほぼゼロです。

サービス	月額概算
Lambda（8関数）	$0〜
Step Functions	$0〜
EventBridge	$0〜
SNS	$0〜
CloudTrail（未設定の場合）	$2〜

CloudTrailがすでに有効な環境では追加費用ゼロで導入できます。

おわりに

TagWatchmanはSCPが使いづらい小規模チームでも、タグ管理によるセキュリティガバナンスを実現することを目的に作りました。

「隔離してから人間が判断する」という設計思想により、誤検知が発生しても安全な構築・保守・運用を実現できます。

フィードバックもお待ちしています。

この記事はZennにも掲載しています。