LASSIC Media らしくメディア
クラウドセキュリティと責任共有モデル
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- クラウドセキュリティは事業者と利用者が責任を分担する仕組みであり、範囲の誤解が設定ミスや事故につながります。
- IaaS・PaaS・SaaSではサービス形態によって利用者が担う責任範囲が変わり、経営として把握する必要があります。
- IAM権限・設定・暗号化・監視といった利用者側の対策は、体制と専門知識をどう確保するかが実務上の課題です。
目次
責任共有モデルの理解が経営課題である理由
クラウドセキュリティにおける責任共有モデルとは、クラウド事業者と利用者企業がセキュリティ対策の責任範囲をあらかじめ分担する考え方を指します。AWSは「AWSクラウドで提供されるすべてのサービスを実行するインフラストラクチャを保護する責任」を負う一方、利用者側にはデータ管理・IAM（Identity and Access Management。利用者の権限を管理する仕組み）権限設定・アプリケーションのパッチ適用などの責任が残ると説明しています*1。
「クラウドを使えば守られる」という理解は正確ではありません。実際にはクラウド事業者が保護するのは基盤部分にとどまり、その上で動くデータやアプリケーションの保護は利用者企業の役割として残ります。この境界線を経営層や情報システム部門が正しく認識していないと、対策が漏れた領域が生まれやすくなるのではないでしょうか。
実務上の設定ミスや権限管理の不備の多くは、責任範囲の誤解に起因すると考えられます。ストレージの公開範囲設定や過剰な権限付与といった問題は、クラウド事業者側の対策ではカバーされない利用者側の責任領域です。
クラウド活用が事業の前提になった以上、責任共有モデルの理解は情報システム部門だけの課題ではありません。予算配分・体制構築・委託先選定を判断する経営層こそ、範囲の分担を把握しておく必要があります。
「クラウドのセキュリティ」と「クラウド内のセキュリティ」の境界線
責任共有モデルの中核にあるのは、「クラウド”の”セキュリティ」と「クラウド”内”のセキュリティ」という2つの概念です。AWSはこの2軸で責任範囲を整理しています*1。
クラウド「の」セキュリティ — 事業者が担う基盤保護
AWSの説明によれば、事業者はハードウェア・ソフトウェア・ネットワーキング、そしてクラウドサービスを稼働させる施設で構成されるインフラストラクチャの保護に責任を持ちます*1。具体的にはデータセンターの物理的な保護、サーバーやストレージなどの基盤機器、仮想化を実現するハイパーバイザ（1台の物理サーバー上で複数の仮想マシンを稼働させる基盤ソフトウェア）の管理が含まれます。
クラウド「内」のセキュリティ — 利用者が担うデータとアプリの保護
一方で利用者企業は、クラウド上に構築したシステムの「中身」を守る責任を負います。AWSはデータの管理（暗号化オプションを含む）、アセットの分類、IAMツールによる適切な権限設定を利用者の責任として明示しています*1。ゲストOS（利用者が管理するサーバー上のOS)の更新やセキュリティパッチの適用、アプリケーションソフトウェアの管理、ファイアウォールに相当するセキュリティグループの設定も利用者側の役割です*1。
パッチ管理・構成管理は双方が分担する領域
パッチ適用や構成管理は片方だけの責任ではなく、レイヤーごとに分担されます。AWSはインフラストラクチャの不具合に対するパッチ適用や修復に責任を負う一方、利用者はゲストOSおよびアプリケーションのパッチ適用に責任を負うと整理しています*1。構成管理についても、AWSがインフラストラクチャデバイスの構成を保守し、利用者は自らのOS・データベース・アプリケーションの構成を管理する分担になります*1。この整理を理解しておくと、どの層で不具合が起きた際に誰が対応すべきかの切り分けがしやすくなるはずです。
IaaS・PaaS・SaaSで変わる利用者の責任範囲
責任共有モデルの適用範囲は、利用するクラウドサービスの形態によって変化します。AWSはIaaS（Infrastructure as a Service。仮想サーバーなど基盤を提供する形態）とPaaS的な抽象化サービスとで、利用者の責任範囲が異なることを説明しています*1。
Amazon EC2のようなIaaS型サービスを利用する場合、利用者はゲストOSの管理・アプリケーションソフトウェアの管理・セキュリティグループの構成に責任を負うとされています*1。仮想サーバーを自社のサーバーのように扱う形態のため、OSレベルの管理まで利用者の役割になる点が特徴です。
一方、Amazon S3やAmazon DynamoDBのような抽象化されたサービスでは、AWSがインフラストラクチャレイヤー・OS・プラットフォームまで運用し、利用者はエンドポイントにアクセスしてデータを保存・取得する形になります*1。この形態では利用者がOSの管理を意識する必要がなく、データそのものの管理と権限設定に責任範囲が絞られます。SaaS（Software as a Service。完成したアプリケーションをサービスとして利用する形態）ではさらに利用者の管理対象が縮小し、主にデータの取り扱いとアカウント権限の管理が中心になると考えられます。
| サービス形態 | 事業者の主な責任範囲 | 利用者の主な責任範囲 |
|---|---|---|
| IaaS（仮想サーバー等） | 物理設備・仮想化基盤・ネットワーク基盤 | ゲストOS管理・パッチ適用。 アプリ管理・ファイアウォール設定。 データ・権限管理 |
| PaaS・抽象化サービス | 基盤設備・OS・プラットフォーム運用 | データの保存・取得。 アクセス権限の設定・暗号化設定 |
| SaaS（業務アプリ等） | アプリケーション本体・基盤全般の運用 | アカウント権限管理・データ入力内容の管理 |
この表からわかるとおり、IaaSに近いほど利用者の責任範囲は広く、SaaSに近いほど事業者側が担う範囲が広がります。自社が利用しているサービスがどの形態に該当するかを把握しないまま運用すると、対応すべき責任範囲を見誤るおそれがあるでしょう。
IAM・設定・暗号化・監視 — 利用者が担う4つの対策領域
責任共有モデルにおいて利用者企業が担う対策は、IAM権限管理・設定管理・データ暗号化・ログ監視の4領域に整理できます。それぞれに必要な知識と工数が異なる点を押さえておく必要があります。
IAM権限管理 — 最小権限の原則を運用に落とし込む
IAMは利用者に付与するアクセス権限を細かく制御する仕組みです。業務上必要な範囲だけに権限を絞る「最小権限の原則」を守るには、部署異動や退職に応じた権限の棚卸しを継続的に行う体制が欠かせません。権限設定を内製で運用するには、クラウドの権限モデルに関する専門知識と、定期的な棚卸しに充てる工数の両方が必要になります。
設定管理 — 公開範囲やアクセス制御の適正化
ストレージやデータベースの公開範囲、ネットワークのアクセス制御といった設定項目は多岐にわたります。設定を誤ると、意図せず外部からアクセス可能な状態になってしまう可能性があるでしょう。設定項目を正しく理解し継続的に点検するには、サービスごとの仕様変更を追い続ける専門人材の配置が求められます。
データ暗号化 — 保管時・通信時の両面で対応する
データの暗号化は、サーバーに保管されている状態（保管時）とネットワークを移動している状態（通信時）の両方で検討する必要があります。暗号化鍵の管理方法や適用範囲の設計を誤ると、想定していた保護水準を確保できない事態にもなりかねません。
ログ監視 — 異常の早期検知につなげる体制
アクセスログや操作履歴の監視は、不正アクセスや設定変更を早期に検知するための要です。膨大なログの中から異常な兆候を見つけ出すには、監視ルールの設計と継続的なチューニングを担う人材が必要になります。これらの領域を情報システム部門の担当者数名だけで内製するのは、通常業務と並行しながら対応することになり、負荷が大きくなりがちです。
公開設定ミス・権限過多・監視不足 — ありがちな抜け漏れ
責任共有モデルにおける利用者側の対策は、抜け漏れが起きやすい領域でもあります。代表的な3つのパターンを押さえておくと、自社の対策状況を点検する際の参考になります。
公開設定ミス — アクセス制御の初期設定を見直さないまま運用
ストレージやデータベースの公開範囲設定を初期状態のまま放置すると、意図しない第三者からアクセス可能な状態が続いてしまいます。公開設定を誤った状態が長期間気づかれずに放置されると、情報漏えいや不正利用につながる可能性が高まるでしょう。設定変更の履歴を追跡できる仕組みがなければ、いつ誰が変更したかの特定にも時間を要すると考えられます。
権限過多 — 必要以上のアクセス権を付与したまま放置
業務効率を優先して広めの権限を付与したまま、その後の見直しを行わないケースが見られます。退職者や異動者のアカウントに権限が残り続けると、不正アクセスが発生した際の被害範囲が広がりかねません。権限の棚卸しには利用状況の可視化と定期的な確認作業が必要で、対象アカウント数が多いほど工数も増える点に注意が必要です。
監視不足 — ログを取得していても確認体制がない
ログ自体は取得していても、異常を検知するための確認体制やアラート設定が整っていない状況も少なくありません。監視の仕組みがなければ、不正アクセスや設定変更が発生してから発覚まで時間がかかり、被害が拡大するおそれがあるでしょう。監視ルールの設計・運用には、クラウド環境特有の知識を持つ人材の関与が欠かせません。
責任範囲を明確にした上で外部の専門知見を活用する視点
責任共有モデルを正しく理解しても、利用者側の責任範囲をすべて内製で対応できるとは限りません。IAM設計・設定点検・暗号化運用・ログ監視という異なる専門性を同時に確保する必要があるためです。
内製で体制を構築する場合、クラウド環境の仕様変更を継続的に追い、複数のサービスにまたがる設定を点検できる人材を育成・採用しなければなりません。専門人材の確保には一定のリードタイムを要すると考えられ、事業拡大のスピードに体制構築が追いつかない企業も出てくるはずです。
外部の専門パートナーに設定運用や監視の支援を委託した場合、自社で体制を一から構築するのに比べて、既存のチェック項目や運用ノウハウを活用できる違いがあります。責任共有モデルにおいて利用者が担うべき範囲を洗い出し、優先順位をつけて対策する進め方についても、他社支援で培った知見をもとにした助言を受けられる可能性があるでしょう。
LASSICは元請としてシステムの保守・運用を受託する立場から、クラウド環境の設定点検や運用監視に関する知見を蓄積しています。責任共有モデルの理解を前提に、自社がどこまで対応し何を委託すべきかを整理したい企業様は、体制構築の初期段階から相談できる先を持っておくとよいのではないでしょうか。
まとめ：クラウドセキュリティ責任共有モデルの3つの判断軸
本稿では、クラウドセキュリティにおける責任共有モデルを経営視点で整理しました。要点を3つに集約すると次の通りです。第一に、クラウド事業者が担う「クラウドのセキュリティ」と利用者が担う「クラウド内のセキュリティ」を正しく区別する必要があります。第二に、IaaS・PaaS・SaaSといったサービス形態によって利用者の責任範囲が変わるため、自社の利用実態に合わせた把握が欠かせません。第三に、IAM・設定・暗号化・監視という利用者側の対策領域は専門性と工数を要するため、内製と外部活用の判断が経営課題になるのではないでしょうか。
よくある質問
責任共有モデルはどのクラウド事業者にも共通する考え方ですか。
基本的な考え方は主要なクラウド事業者に共通しています。本稿ではAWSの説明を基に整理しましたが、事業者側が基盤を保護し利用者側がデータやアプリを保護するという分担の構造自体は、他のクラウドサービスでも同様の考え方が採用されています*1。契約するサービスごとに公式ドキュメントで責任範囲を確認することをおすすめします。
クラウド事業者と契約すればセキュリティ対策は不要になりますか。
不要にはなりません。クラウド事業者が保護するのは基盤インフラの部分であり、データの管理やIAM権限の設定、アプリケーションのパッチ適用などは利用者側の責任として残ります*1。契約後も自社が担う範囲の対策を継続する必要があります。
IaaSとSaaSでは利用者の対策負担にどれくらい差がありますか。
IaaSの方が利用者の管理対象が広くなります。IaaSではゲストOSの管理やアプリケーションの管理まで利用者側の責任になるのに対し、SaaSでは事業者がアプリケーション本体まで運用するため、利用者はアカウント権限やデータの取り扱いを中心に対応する形になります*1。
責任共有モデルの理解が不足するとどのような問題が起きますか。
公開設定ミスや権限の付与しすぎといった問題につながりやすくなります。事業者が対策してくれる範囲だと誤解した領域が放置され、結果として情報漏えいや不正アクセスの原因になる可能性があります。自社の責任範囲を明確にした上で点検体制を整えることが大切です。
利用者側の対策は外部に委託できますか。
設定点検や監視業務を専門とする事業者に委託することが可能です。IAM設計・設定管理・暗号化・ログ監視という複数の専門性を自社だけで揃えるのが難しい場合、外部パートナーの知見を活用する選択肢があります。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：Amazon Web Services, Inc.「責任共有モデル」https://aws.amazon.com/jp/compliance/shared-responsibility-model/
