LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

クラウド移行のセキュリティ設計とは、責任共有モデルに基づく対策

クラウド移行のセキュリティ設計とは、AWS・Azure・Google Cloudが公表する責任共有モデルに基づく対策の総称です^*1。具体的にはIAM(Identity and Access Management。利用者やシステムの権限を管理する仕組み)権限・データ暗号化・ネットワーク境界などを、移行計画に組み込むことを指します。クラウド事業者側はインフラの物理的な保護を担いますが、設定そのものは利用者側の責任です^*1。この境界を移行前に理解しておくかどうかで、移行後のリスクの大きさが変わってきます。

AWSはこの境界を「セキュリティ・オブ・ザ・クラウド」と「セキュリティ・イン・ザ・クラウド」という2つの言葉で説明しています^*1。前者はAWS自身が担う範囲であり、後者はゲストOSの管理やIAMツールの利用など利用者が担う範囲です^*1。オンプレミスからの移行では、この利用者側の範囲をどこまで自社で設計・運用できるかが最初の論点になります。

責任共有モデルにおける、クラウド事業者と利用者の責任の境界

セキュリティ・オブ・ザ・クラウド——クラウド事業者が担う範囲

クラウド事業者が担う範囲には、データセンターの物理的な保護やハードウェア、ネットワーク基盤の運用が含まれます^*1。AWSはこの範囲を「すべてのサービスを実行するインフラの保護」と説明しています^*1。利用者側がここに手を入れることはできませんが、逆にここで生じた不具合の責任も利用者側にはありません。

ただしサービスの抽象度によって境界は変わります。EC2のようなIaaS型サービスではOSやアプリケーション、セキュリティグループの設定まで利用者側の責任です^*1。一方でS3やDynamoDBのようなマネージドサービスでは、AWS側がインフラとOSを運用し、利用者側はデータ管理とIAM設定に責任を持ちます^*1。この違いを移行対象ごとに整理しておく必要があります。

セキュリティ・イン・ザ・クラウド——利用者が担う範囲

利用者が担う範囲には、ゲストOSの更新・パッチ適用、セキュリティグループの設定、データの分類と暗号化オプションの選択、IAMツールの利用が含まれます^*1。移行元のオンプレミス環境で担っていた責任の一部は、クラウド側では利用者に残ったまま形を変えます。

Azure・Google Cloudも同様の考え方を採用しています。Azure Well-Architected Frameworkはセキュリティの柱として、ID・アクセス管理やネットワーク保護、暗号化の利用を設計原則に含めています^*2。Google Cloudのエンタープライズ基盤ガイドでも、組織階層に基づくIAM設計と共有VPCによるネットワーク分離が推奨されています^*3。3社の文書に共通するのは、権限・暗号化・ネットワークの3点を移行の初期段階から設計する姿勢です。

IAM権限設計——移行時に見直す最小権限とロール分離

オンプレミス環境では、サーバーへの物理アクセスや社内ネットワークの境界が一定の防御線になっていました。クラウド環境ではこの防御線がなくなるため、IAMの権限設計が実質的な境界線になります。AWS Well-Architected Framework のセキュリティの柱でも、IDとアクセス管理は主要な設計領域の一つに位置づけられています^*2。

移行時に見直すべき点は、既存システムの管理者権限をそのままクラウド上のIAMロールに引き継いでいないかどうかです。オンプレミス時代の「管理者は全権限を持つ」という運用を移行後も続けると、必要以上に広い権限を持つロールが残ります。移行を機に、業務ごとに必要な操作だけを許可する最小権限の設計へ切り替えることが実務上の課題になります。

ロール分離も同時に検討すべき事項です。移行作業を行うロールと、移行後の運用を行うロールを分けておくと、作業ミスの影響範囲を限定できます。Google Cloudのガイドでも、職能別のグループに権限を割り当てる方式が推奨されています^*3。権限の棚卸しは移行対象システムが多いほど工数が膨らむため、対象範囲の見極めが移行計画の初期に求められます。

データ暗号化——保管時と転送時の対策を移行工程に組み込む

データ暗号化は、保管時(at rest)と転送時(in transit)の2つの観点で検討する必要があります。移行作業そのものがデータを転送する工程であるため、移行中の暗号化設定は特に見落とされやすい部分です。

鍵管理の設計も暗号化対策の一部です。Google Cloudのエンタープライズ基盤ガイドでは、暗号鍵の管理と監査を専任チームが担う専用プロジェクトを設ける構成が示されています^*3。移行後にどの部署が鍵のライフサイクルを管理するかを、移行計画の段階で決めておくことが望まれます。

ネットワーク境界の再設計——VPCとセキュリティグループでの遮断

オンプレミス環境の境界防御は、ファイアウォールという単一の防御線に依存する構成が一般的でした。クラウド環境ではVPC(Virtual Private Cloud。クラウド上に構築する仮想的な専用ネットワーク)の分割と、セキュリティグループの設定を組み合わせた複数層の境界設計が基本になります。

移行時にはまず、既存のネットワーク構成をVPCのサブネット構成へどう対応させるかを検討します。Google Cloudの基盤ガイドでは、環境ごとに分離した共有VPCを用い、オンプレミスとクラウド間の通信経路をすべて非公開に保つ構成が示されています^*3。パブリックサブネットとプライベートサブネットを分け、外部公開が必要なコンポーネントだけを限定する設計が求められます。

セキュリティグループは、インスタンス単位で通信を許可・拒否するルールの集合です。移行時にオンプレミスのファイアウォールルールをそのまま複製すると、不要な範囲まで通信を許可したセキュリティグループが残ることがあります。移行を機に、通信が必要な範囲だけに絞ったルールへ整理し直す作業が欠かせません。

設定ミスの防止——公開バケットなど移行中に起こりやすい事故

クラウド移行で実際に起こりやすい事故の一つが、オブジェクトストレージの公開設定ミスです。AWSはS3のBlock Public Accessという機能を提供しています^*4。バケットポリシーやACL(Access Control List。リソースへのアクセス権限の一覧)の設定にかかわらず、公開アクセスを一括で遮断できます^*4。

この機能は組織単位・アカウント単位・バケット単位のいずれでも設定でき、複数の設定が競合した場合は最も厳格な設定が優先されます^*4。移行作業では新規バケットを大量に作成する場面が発生しやすく、個別のバケットごとに公開範囲を確認していると設定漏れが生じます。アカウント単位で一括ブロックしたうえで、必要な範囲だけ個別に許可する運用が現実的です。

設定ミスは公開範囲だけでなく、移行の一時的な作業でも発生します。移行検証のために一時的に緩めた権限やネットワーク経路を、検証後に戻し忘れる事例は珍しくないでしょう。移行計画には、一時的に緩和した設定の復元をチェックリストとして組み込んでおく必要があります。

ログ・監査とCSPMによる移行後の継続監視

セキュリティ設計は移行完了時点で終わるものではありません。移行後も設定は日々変化するため、継続的な監視の仕組みが欠かせません。AWS Well-Architected Framework のセキュリティの柱でも、イベントの検出と対応は主要な設計領域として扱われています^*2。

継続監視の手段として広がっているのがCSPMです。CSPM(Cloud Security Posture Management)とは、クラウド環境の設定状態を継続的に評価し、リスクのある設定を検知する仕組みを指します。IAM Access Analyzer for S3のように、公開設定になっているバケットを自動検知する機能も、この考え方に含まれます^*4。設定変更のたびに人手で確認する体制では、変更頻度が増えるほど検知が追いつかなくなります。

ログの集約と保管も監視体制の土台です。Google Cloudの基盤ガイドでは、セキュリティ・監査に関するログを一元管理用のプロジェクトへ集約し、長期保管する構成が示されています^*3。CIS Benchmarks(セキュア設定に関する専門家の合意に基づくガイドライン)には、AWS・Azure・Google Cloud向けの設定基準が用意されています^*5。監視ルールの設計時にこれらを参照する事業者が増えています。

内製と外注の分かれ目——セキュリティ設計をどこまで社内で担うか

ここまで見た通り、クラウド移行のセキュリティ設計はIAM・暗号化・ネットワーク・監視という複数領域にまたがります。対象システムが少数で、既存の運用担当者がクラウドの権限管理に慣れている場合は、自社で設計・運用まで担える場合もあります。

判断が難しくなるのは、対象システムが多い環境や、複数のクラウドを併用するマルチクラウド構成です。AWS・Azure・Google Cloudそれぞれで責任共有モデルの範囲や設定方法が異なるため、担当者が各社の仕様を個別に把握する必要があります^*1*2*3。この状態で移行スケジュールが優先されると、セキュリティ設計の検証が後回しになりかねません。

専門パートナーへ委託する場合は、依頼範囲の明確化が選定の分かれ目になります。IAM設計の棚卸しからネットワーク境界の再設計、CSPMによる継続監視の立ち上げまでを一括で依頼できるかどうかが判断のポイントです。内製では通常業務と並行して対応することになり、検証に割ける時間が限られる場合があります。

。移行対象システムの数やマルチクラウド構成の有無によって、必要な工数は変わってきます。現状の構成を診断したうえで、内製・外注の切り分けを検討することが実務的です。

まとめ：クラウド移行のセキュリティ設計で押さえる3つの判断軸

本稿ではクラウド移行のセキュリティ設計を、責任共有モデルを軸に整理しました。要点は3つに集約できます。第一に、AWS・Azure・Google Cloudいずれも、事業者側が担うインフラの保護と、利用者側が担う設定・権限管理を明確に区分しています^*1*2。第二に、IAM権限設計・データ暗号化・ネットワーク境界の3領域は、移行計画の初期段階から組み込む必要があります。第三に、移行後も設定は変化し続けるため、CSPMなどによる継続監視の体制構築が内製と外注を分ける判断材料になります。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：AWS「Shared Responsibility Model」（https://aws.amazon.com/compliance/shared-responsibility-model/）
2. *2　出典：AWS「Security Pillar – AWS Well-Architected Framework」（2024年11月6日公表）（https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html）
3. *3　出典：Google Cloud「Enterprise foundations blueprint」（Cloud Architecture Center）（https://cloud.google.com/architecture/security-foundations）
4. *4　出典：AWS「Blocking public access to your Amazon S3 storage」（Amazon S3 User Guide）（https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-control-block-public-access.html）
5. *5　出典：Center for Internet Security「CIS Benchmarks」（https://www.cisecurity.org/cis-benchmarks）

Tweet