CompTIA SY0-701: クラウド、仮想化、コンテナセキュリティ — 学習ガイド

By Laurynas Brazys · 20 July 2026 · #comptia #sy0-701 #certification #exam-prep #study-guide

こちらの一部です： CompTIA Security+ SY0-701 — 学習ガイド. 検証済みの解答で練習： CompTIA試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.

現代の企業が、単一の自己完結型データセンターのみで事業を運営することは稀です。ワークロードは、パブリッククラウドプロバイダー、プライベート仮想化クラスター、コンテナオーケストレーター、そして短命なサーバーレス関数にまたがっています。それぞれの抽象化レイヤーは、脅威モデル、コントロールサーフェス、そして決定的に重要なこととして、誰がどのセキュリティコントロールに責任を持つか、という点を変化させます。

責任共有モデル

主要なクラウドプロバイダーはすべて、顧客とクラウドサービスプロバイダー（CSP）との間でセキュリティの責務を分担する責任共有モデルを公開しています。この境界線は、サービスティアによって変動します。

Infrastructure as a Service (IaaS) — Amazon EC2、Azure Virtual Machines、Google Compute Engine — では、CSPは物理的な施設、ハードウェア、ハイパーバイザー、およびネットワークファブリックを保護します。ハイパーバイザーより上のすべてが顧客の責任範囲です。具体的には、ゲストオペレーティングシステム、パッチ適用、ホストベースのファイアウォール、ミドルウェア、ランタイム、アプリケーションコード、ID設定、そしてデータそのものです。企業がEC2インスタンスにMySQLデータベースをデプロイした場合、そのデータベースの保護は完全に顧客の責任です。

Platform as a Service (PaaS) — AWS RDS、Azure App Service、Google App Engine — では、プロバイダーはさらにオペレーティングシステム、データベースエンジンのパッチ適用、およびランタイムも管理します。顧客は引き続き、アプリケーションコード、データ分類、アクセス制御、ネットワーク公開ルール、およびID管理に責任を負います。

Software as a Service (SaaS) — Microsoft 365、Salesforce、Workday — では、プロバイダーがほぼスタック全体を管理します。顧客に残された責任も些細なものではありません。アカウントのプロビジョニングとデプロビジョニング、MFAの強制、データ分類、共有権限、DLP設定、および企業のIDプロバイダーとの統合などです。「すべてのユーザー」に給与データを公開するよう誤って設定されたSharePointサイトは、Microsoftの侵害ではなく、テナント管理者の侵害です。

クラウドに移行すればすべてのセキュリティ責任がプロバイダーに移ると考えるのは、根強い誤解です。設定ミスのあるS3バケット、公開されたElasticsearchクラスター、漏洩したAPIキーが関わるデータ侵害は、CSPの侵害ではなく、ほぼ例外なく顧客側のエラーに起因します。

仮想化とハイパーバイザーのリスク

仮想化は、ハイパーバイザーを使用して物理ハードウェアをプールし、論理的なゲストを作成します。VMware ESXi、Microsoft Hyper-V、KVMなどの**Type 1 (ベアメタル)ハイパーバイザーは、ハードウェア上で直接実行されます。VirtualBoxのようなType 2 (ホスト型)**ハイパーバイザーは、汎用OS上で実行され、本番ワークロードには不向きです。

仮想化に特有の主な脅威は、VMエスケープとハイパーバイザーの侵害です。VMエスケープは、ゲスト内の悪意のあるコードが仮想化の境界を突破し、ハイパーバイザーまたは隣接するVM上で実行される場合に発生します。過去の例としては、CVE-2015-3456（VENOM、QEMUのフロッピーコントローラー内）や、さまざまなVMware Toolsの脆弱性があります。1つのハイパーバイザーが複数の信頼ゾーンにまたがる数百のワークロードをホストする可能性があるため、エスケープが成功すると不相応なアクセス権が得られてしまいます。

緩和策には、厳格なハイパーバイザーのパッチ適用、ゲスト追加機能や未使用のエミュレートされたハードウェアの最小化、機密性に応じたワークロードの個別クラスターへの分離、および管理プレーンの分離が含まれます。vCenterサーバー、ESXi管理インターフェース、およびクラスターAPIは、MFAを備えた特権ジャンプホストからのみ到達可能な専用の管理ネットワークに配置する必要があります。

その他の懸念事項として、VMスプロール（時間の経過とともに蓄積される、放置されパッチが適用されていないVM）や、廃止されたVMのメモリやストレージが、別のテナントに割り当てられる前に適切にゼロクリアされないリソースの再利用などがあります。

コンテナ、マイクロサービス、カーネル共有

コンテナはアプリケーションとその依存関係をパッケージ化しますが、VMとは異なり、ホストオペレーティングシステムのカーネルを共有します。Docker、containerd、CRI-Oはコンテナのライフサイクルを管理し、Kubernetesはそれらを大規模にオーケストレーションします。この軽量な分離は、ミリ秒単位の起動や高密度な集約といった特徴であると同時に、主要なリスクでもあります。

コンテナの分離はVMの分離と同等ではありません。コンテナ内からカーネルの脆弱性を悪用されると、ホストとそこにある他のすべてのコンテナが侵害される可能性があります。名前空間（PID、network、mount、UTS、IPC、user）とcgroupsは分離を提供しますが、これらは単一の攻撃対象領域を共有するソフトウェア構成要素です。

コンテナセキュリティには、パイプライン全体にわたるコントロールが必要です。

# Example: Pod security context enforcing hardening
securityContext:
  runAsNonRoot: true
  runAsUser: 10001
  readOnlyRootFilesystem: true
  allowPrivilegeEscalation: false
  capabilities:
    drop: ["ALL"]
  seccompProfile:
    type: RuntimeDefault

イメージはデプロイ前に脆弱性スキャン（Trivy、Snyk、Clair）を行い、最小限のベースイメージ（distrolessやAlpine）からビルドし、イメージ署名が強制された（Cosign、Notary）信頼できるレジストリからのみプルする必要があります。ランタイム保護ツール（Falco、Aqua、Sysdig）は、コンテナの振る舞いを監視し、予期しないプロセスの実行やネットワーク接続などの異常を警告します。

クラウドセキュリティポスチャとIAM

クラウドのIAMは、オンプレミスのActive Directoryとは重要な点で異なります。AWSでは、IAMポリシーはユーザー、グループ、またはロールにアタッチされるJSONドキュメントであり、有効なアクセス許可は、アイデンティティベースのポリシーとリソースベースのポリシーの積集合であり、明示的な拒否（deny）が常に優先されます。

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:GetObject"],
    "Resource": "arn:aws:s3:::company-data/*",
    "Condition": {
      "StringEquals": {"aws:RequestedRegion": "us-east-1"}
    }
  }]
}

**Cloud Security Posture Management (CSPM)**ツールは、セキュリティベンチマーク（CIS AWS Foundations、NIST）に対してクラウド構成を継続的にスキャンし、公開S3バケット、過度に許可的なセキュリティグループ、無効化されたCloudTrailロギング、暗号化されていないEBSボリュームなどを検出します。**Cloud Access Security Brokers (CASBs)**は、ユーザーとクラウドサービスの間に位置し、SaaSアプリケーションに対してDLP、アクセスポリシー、および脅威検出を強制します。

実例：設定ミスによるS3バケットからのPII漏洩

あるヘルスケアのスタートアップ企業は、患者の受付フォームをS3バケットに保存していました。このバケットは、開発スプリント中にパブリック読み取りアクセスが許可された状態で作成され、本番稼働前にアクセス制限がかけられることはありませんでした。そのバケットは、DNSのブルートフォース攻撃とAWS S3バケットの列挙手法を組み合わせたセキュリティ研究者によって発見されました。氏名、生年月日、保険ID、主訴の説明などを含む約87,000件の患者記録が、認証なしでアクセス可能な状態でした。このスタートアップはCSPMツールを導入しておらず、自動化された設定スキャンも行っていませんでした。s3-bucket-public-read-prohibitedをチェックする基本的なAWS Configルールがあれば、作成から数分以内にこの設定ミスを検知できたはずです。このインシデントは、HHS（米国保健福祉省）の調査、45万ドルの和解金、そして評判への損害につながり、最終的に同社が不当に低い評価額で買収される一因となりました。

← アプリケーションとWebセキュリティ · すべてのドメイン · データセキュリティ、プライバシー、暗号技術 →

これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →