「セキュリティ監査は死んだ」というブログが以前結構話題になっていた。

https://note.com/grandchildrice/n/n871088ba195f

自分もその時に読んだが、確かにその通りだなと思った。MythosをはじめとするAIによる攻撃からの完全防御は非常に難しく、Linuxのような著名OSSや多くの大企業でさえ(もしくは大企業ゆえかもしれないが....)、不正アクセス、サプライチェーンなど様々な攻撃に侵害されている。

各社が対策を練っている最中でもあると思うが、人的ミスもある以上攻撃を防ぐのはなかなか困難になっていくのではないかと思わざるを得ない。

ここで昨今話題になっているのが、GitHubの不正アクセスだ。私はこのサプライチェーンが広まっている現在ではGitHubはかなり危うい存在だと考えている。

GitHubの1個人、1アカウントというそもそもの設計がこのサプライチェーンを防ぐ上ではなかなか厳しいものにしていると言わざるを得ないだろう。このGitHub上での攻撃者のアクセス経路というものをかなり精査していく必要があるように思える。

そんな中私が注目しているのが、TerraformなどのInfrastructure as Codeだ。

laCはAWSなどのインフラの設定を権限設定、デプロイ経路・Security Groupなどコードで設定をなんでも書くことができる。これはCoding Agentsでの開発体験を劇的に向上される素晴らしいものだと私は思っているが、それは攻撃者側から見ても同じだという皮肉でもある。

ChatGPTに簡単に聞いた感じだと、

GitHub Actionsに長期AWSキーを置かない

OIDC federationで短命credential化

main branch保護

mandatory review

apply権限とmerge権限を分離

Terraform plan/apply分離

本番applyは別system

drift detection

organization SCPで最終防衛線

break-glass account分離

secretsをTerraform stateに置かない

state backend暗号化

apply結果を監査ログへ

などを挙げていた。

これも皮肉だが、laC化されたインフラは、人間にとって管理しやすいだけでなく、AIにとっても解析しやすい。

IAM権限・デプロイ経路などもさらされる対象になるだろう。

我々は残念ながらlaCがない開発体験には絶対に戻ることはできない(それはそれで事故が起きると思われる)。

この開発体験と天秤にかけて設計をしていく必要が出てきているのかもしれない。

詰まるところはAWS Consoleが奪われるか、GitHubのログイン権限奪われるか？という違いではあるが、そこには天と地の違いがありそうな感覚がある。

GitHubの不正アクセスが起きた時にどのような情報がハッカーに渡るのか？そこまで考えて設計する時代になってしまっているのかもしれない。

今までは秘匿情報を守る必要があった。これからはシステムの構造情報すらも守る時代になっていくのかもしれない