AWSのSecurity Groupが外された経緯を知る方法

はじめに

AWSの開発に関わっていると、ある日突然EC2が通信できなくなったと連絡があり、原因を調べると「アタッチしていたはずのSecurity Groupがデタッチされていたため」ということがあります。
この場合、一次対処としてはSecurity Groupをアタッチし直すことになるでしょう。
その後、業務では根本原因を追求するため、どうしてSecurity Groupが外れたのかを調査することになります。
CloudTrailのイベント履歴画面で、イベント名「ModifyNetworkInterfaceAttribute」を確認すればOKです。

ModifyNetworkInterfaceAttributeがないか調査

試しにSecurity Groupを複数アタッチしたEC2を用意し、Security Groupをデタッチします。
その後CloudTrailを見ると、以下のようにイベントが上がっています。
このイベントが、Security Groupの変更によって発生したものです。

上記の画面から、誰がどこから、どのENI(ネットワークインタフェース)に対してSecurity Groupの操作をしたかが分かります。

何が外された(デタッチされた)のかを知る

同じ画面上では、この操作によって、結果、ENIにどのSecurity Groupがアタッチされている状態となったかが分かります。

つまり、過去のModifyNetworkInterfaceAttributeのイベントを追いかけていけば、Security Groupのアタッチ状態の遷移を追うことができます。

検索条件(フィルタ)でENI IDを指定して調査

EC2にアタッチされているENIのID(eni-)が分かれば、イベント履歴画面でリソース名にENIのIDを指定して検索すると、ENIを絞り込んで、遷移を追うことができます。
Security Groupをデタッチする操作は、厳密にはSecurity Groupに対する操作ではなく、ENIに対する操作になりますので、ENIで絞り込んで調査します。

※参考※ 検索条件(フィルタ)でSecurity Group IDを指定して調査

Security GroupのID(sg-)が分かれば、イベント履歴画面でリソース名にSecurity GroupのIDを指定して検索すると、そのSecurity Groupだけに絞り込んで調査できます。
ただし上記で説明したように、Security GroupのデタッチはENIに対する操作ですので、デタッチを追うにはENIで絞り込む必要があります。

これでSecurity Groupがデタッチされた経緯を調査でき、犯人探しができるようになります。

えっ・・・経緯って言うけど、そもそも何でデタッチしたのかが分からないじゃないかって？
それを知るには、当事者にカツ丼を食べさせる必要があります。