【要約】“DROP DATABASE”: What not to do after losing an IT job [Ars_Technica] | Summary by TechDistill
> Source: Ars_Technica
Execute Primary Source
// Problem
解雇プロセスにおける権限管理の不備が、甚大なセキュリティインシデントを招いた。雇用主が双子の兄弟を解雇した際、一人の権限は即時停止したが、もう一人の権限削除が漏れた。この管理ミスにより、以下の問題が発生した。
- ・解雇直後の従業員が、依然として社内ネットワークへアクセス可能であった。
- ・特権アカウントの無効化が、全システムに対して同期されていなかった。
- ・高リスクな人物に対する、監視体制や即時遮断の仕組みが欠如していた。
// Approach
攻撃者は、権限が残存している隙を突き、破壊と隠蔽を迅速に行った。解雇直後のわずか1時間足らずの間に、以下の手法を用いて攻撃を完遂した。
- ・
DROP DATABASE dhsproddb等のコマンドを用い、DHSのDBを直接削除。 - ・AIツールを活用し、SQL ServerやWindowsのログ消去方法を調査。
- ・証拠隠滅のため、業務用PCのOSを再インストールし、操作痕跡を抹消。
// Result
攻撃者は、政府機関の重要データを破壊し、大量の機密情報を窃取した。このインシデントにより、以下の被害が発生した。
- ・96の政府系データベースが削除・破壊された。
- ・EEOCのファイル1,805件および、450人以上の連邦納税情報を窃取。
- ・最終的に加害者は逮捕され、有罪判決を受けた。
Senior Engineer Insight
> IAMの自動化は、単なる効率化ではなく生存戦略だ。解雇等のイベントをトリガーに、全システムへの権限剥奪を即時実行するワークフローが必須である。また、特権IDの操作には、ログの外部保存とリアルタイム監視を組み合わせるべきだ。ログの消去を許す現状の構成では、事後調査すら困難になる。インシデント発生時の「キルスイッチ」の設計を、システムアーキテクチャに組み込むべきである。