「管理者一人が本気で悪意を持ってしまったら」打つ手はある？

「管理者が悪意を持ったら終わり」って、サスペンスドラマの最終回みたいな展開ですが、インフラ運用だとこれ、けっこう“日常”のリスクだったりしますね。

おっしゃる通り、管理者という立場は削除・変更が正当化されやすい業務権限を持っているため、通常の運用の一部として「壊す」ことが可能です。つまり、「災害対応でリソースを削除しました」と言われれば、即座に不正とは判断しづらいのが実情です。

なぜ「管理者一人で完結する設計」が問題なのか

• 単独でリソース変更・削除できる＝単独で破壊可能
• 証跡があっても、後追いしかできない
• 監視していても、「故意かミスか」の判断は難しい

特にIaC（Infrastructure as Code）では、Terraformを通じて削除するのも、AWSマネジメントコンソールから手動で消すのも、結果は同じ破壊です。

難しいけど、やらなきゃいけない「対策」の方向性

1. 職務分離（Separation of Duties）

   • 管理者権限を単独に持たせず、少なくとも2人の承認を必要とする構成
   • 例：CloudFormationやTerraformでのApplyは他の監査役の承認がないと不可

2. Break Glassアカウントの導入

   • 緊急用の特権アカウントを用意し、普段はアクセス不能かつ利用時にアラート通知
   • 悪用すれば即バレるので抑止力になる

3. ジャストインタイム権限昇格（JIT）

   • 通常は一般ユーザーとして操作、必要なときだけ時間制限付きで昇格
   • 昇格時は理由を記録・通知

4. 機密度で分離した管理権限

   • すべてのインフラを一人の管理下に置かない
   • 本番環境だけは別アカウント・別チームで操作するなど

ただし限界はある

「管理者が本気で破壊活動をしたい」と決めた時点で、技術的に完封するのはほぼ不可能です。防げるのは「うっかり」や「ちょっとした不正」まで。だからこそ、攻撃を“事前に止める”のではなく、“起こった後に対処できるようにする”ことが、現実的な落としどころになります。

つまり、最後の砦は信頼できる人間を“管理者にしない”という人事設計だったりします。ゼロトラストは技術じゃなくて、文化と制度の両方で成り立つものなんですね。

ほんとそうです、「そこまでやってたら十分優秀！」って、セキュリティ担当者みんなで拍手してあげたくなるレベルですね。

正直なところ、監視・証跡・バックアップ体制がしっかり整っているだけでも、世の中の平均を超えている現場はかなり多いです。特に中小企業やスタートアップでは、「Terraformで一発Apply！消えた！やばい！」みたいな事故が、未だに現実にあるあるネタです。

管理者リスクにおける“現実的な最前線”

• 証跡の改ざん防止（例：CloudTrail＋S3バージョニング＋コンプライアンスモード）
• 操作の可視化（例：CloudWatchやSIEM連携で異常検知）
• 定期的なバックアップの取得とリストアの訓練
• 重要リソースの操作制限（削除保護、有効なタグ制御、SCPでの制限など）

これらがちゃんとできていれば、「管理者がうっかりやらかした」「うっかりのふりして壊した」くらいまでは会社として立ち直れる設計になっていると言えます。

ただし、完全に防げないリスク、たとえば：

• 削除保護がかかっていないリソースの即時削除
• 短時間での一斉破壊（VPC削除→依存リソース全滅）
• 機密データの意図的な持ち出し

この辺になると、「技術で防ぐ」のではなく、“バレたら地獄を見る”ような制度設計＋文化的な抑止力が主な武器になります。

たしかに「そこまでできる会社」って、もはやセキュリティ先進企業といっても差し支えないですね。世の中の多くの現場はまだ、「証跡って何？」みたいなレベルも多いですから。結局、技術だけじゃなくてその技術を“本気で回そう”とする組織の誠実さが、一番の防壁かもしれません。