運用の責務分離
この主題を扱う記事
テスト環境や限定公開ページのBASIC認証について、運用担当がSSM Parameter Storeを入口としてパスワード更新できる構成を整理する。
踏み台サーバを、監査や緊急対応にも耐えられる運用入口として設計する構成を整理する。更新の仕組みは、操作できる画面で確かめられる。
Viewer mTLS を採用したあとに残るのは、秘密鍵をどこで生成し、発行・配布・更新・失効を誰がどう回すかである。鍵の生成場所の選択、3つの操作が別物であること、端末への取り込みで詰まる点を整理する。
セキュリティ対策を一度構築して終わりにせず、運用担当者が定められた入口から安全に更新できる状態を作る。AWSとTerraformによる責務分離の考え方を、実装パターンへ展開できる形で整理する。
Amazon ECSのBlue/Greenデプロイには、CodeDeployに切替を任せる方式と、ECS自身が切替を行うネイティブ方式がある。承認の止め方、構成要素、インフラ管理とデプロイの責務分離の違いを整理し、選び方の判断軸を示す。
ECSの環境変数とシークレットを、インフラ管理値・運用設定値・機密値の3系統に分ける。タスク定義の値の指定方式とTerraformのstateの性質から、誰がどの値を変え、変更がいつ反映されるかを整理する。
IPアドレス制限・BASIC認証・Cognito認証・クライアント証明書は、到達範囲と本人性という独立した2つの軸に分かれる。切り替えは軸を1つずつ動かす2手になり、本人性を替える手だけがSPAとAPIの改修を伴う。9通りの組み合わせごとに残る穴と、管理者が見る対象を整理する。
AWSのサービスを組み合わせるたびに設計をやり直すと、プロジェクトごとに作りがばらつく。ECSを中心とするWebサービスを運用し続けるという目的の単位でTerraformを組み替え、環境ごとの記述を「宣言と配線」に絞る設計の考え方と、それを支える規則・品質の担保・運用の循環を解説する。