DevSecOpsにおけるインフラ担当と運用担当の責務分離

セキュリティ対策を一度構築して終わりにせず、運用担当者が定められた入口から安全に更新できる状態を作る。 AWSとTerraformによる責務分離の考え方を、実装パターンへ展開できる形で整理する。

ページ構成

アプリケーション開発では、エンドユーザーが迷わず操作できるように画面や導線を設計する。同じように、インフラ運用でも、運用担当者が専門的なTerraformコードを理解していなくても、定められた入口から安全に変更できる構成を作ることが重要である。

セキュリティ対策は、導入すること自体よりも、継続して運用できる状態にすることが難しい。テスト環境のBASIC認証や、プライベートネットワークへ接続するための踏み台サーバは、一度作って終わりではない。

こうした場面で問題になるのは、「設定されているか」ではなく、「必要になったときに誰が変更できるか」である。

ここでいうインフラ担当とは、AWSの構成要素やIaCによる構成管理を理解し、ネットワーク、権限、デプロイ、運用変更の反映経路を設計する役割を指す。一方、運用担当とは、日常運用の中で利用者対応、認証情報の更新判断、監査対応、緊急時の一次対応を担う役割である。

DevSecOpsとは、セキュリティ対策を開発・インフラ構築・運用の後段に切り出すのではなく、設計と運用の流れに組み込む考え方である。ただし、セキュリティを組み込むとは、すべてのセキュリティ運用をインフラ担当が抱え続けることではない。

セキュリティ対策は、ネットワーク構成、アクセス権限、認証情報、接続経路など、システム基盤の設計と密接に関係する。そのため、初期構築はインフラ担当が行うことが多い。

しかし、日常的に発生する作業までインフラ担当に残り続けると、以下のような課題が発生する。

これは、セキュリティ機能の有無ではなく、運用設計の問題である。

解決アプローチ

運用担当者にインフラの全権限を渡すのではなく、操作範囲を限定し、変更内容が安全に反映される入口を用意する。ここから先の具体構成は、実装パターンとして個別ページで整理する。

目指す状態は、インフラ担当がすべての運用作業を代行することではない。

インフラ担当は、変更してよい入口、変更してはいけない領域、変更後に自動反映される範囲を設計する。運用担当は、その入口を使って日常作業を進める。

領域	インフラ担当	運用担当
必要なスキル	AWS構成、IaC、権限設計、変更反映経路の理解	AWSの詳細知識は不要。業務上の更新判断と、定められた操作入口の利用
設計	AWSリソース、権限、変更経路、自動化を定義する	業務上必要な更新条件を整理する
日常運用	直接作業を抱え込まない構成を作る	定められた入口から更新する
監査対応	構成と反映経路を説明できるようにする	更新実績、判断理由、対象者への周知を説明する
緊急対応	再作成やローテーションが可能な構成を用意する	必要性を判断し、定められた手順で対応を開始する

この分離により、セキュリティ対策は「設定してあるもの」から「運用できるもの」へ変わる。

以下のページでは、上記の考え方をAWS/Terraform構成に落とし込む例を示す。 Terraformソースそのものは公開しないが、業務課題を実装可能な構成へ変換する考え方を確認できる。

BASIC認証のパスワード更新 — テスト環境や限定公開ページのBASIC認証について、運用担当がSSM Parameter Storeを入口としてパスワード更新できる構成を整理する。
踏み台サーバのOS更新とKey Pair更新 — 踏み台サーバを、監査や緊急対応にも耐えられる運用入口として設計する構成を整理する。

セキュリティ対策は、強い制限を入れるだけでは十分ではない。必要なときに更新でき、誰が何を担当するかを説明でき、監査や緊急対応に耐えられることが重要である。

当社では、AWSリソースを構築するだけでなく、運用担当者が使える変更経路、責務分離、監査対応まで含めたインフラ設計を重視している。セキュリティ対策を「作る」だけでなく、「運用できる形にする」ことが、DevSecOpsにおける実践的な設計である。

アプリケーションがエンドユーザーの操作性を高めるように、インフラ構成も運用担当者の操作性を考えて設計できる。