クラウドセキュリティアーキテクチャとは？原則、フレームワーク、評価方法

企業がデジタルトランスフォーメーションやクラウド移行を進めるにつれ、セキュリティツールも進化する必要があります。クラウドテクノロジーを利用する企業を保護する適切なツールがなければ、データ侵害や情報漏えいなど、深刻なセキュリティ上の問題や脅威にさらされるリスクがあります。

そこで必要になるのがクラウドセキュリティです。クラウドセキュリティとは、クラウド上のデータ、アプリケーション、インフラを保護するために企業が使用するツールや戦略を指します。これには、脅威からビジネスを守るためのポリシー、プロトコル、セキュリティツールが含まれます。クラウドへの移行を検討している組織も、すでにクラウドサービスを日常的に利用している組織も、クラウドセキュリティとそのアーキテクチャの原則を理解することが不可欠です。

クラウドセキュリティアーキテクチャとは？

クラウドセキュリティアーキテクチャは、クラウドセキュリティの基本的な構成要素です。クラウドセキュリティが、クラウドサービスの利用時に組織を保護する方法を指すのに対し、クラウドセキュリティアーキテクチャは、セキュリティツールや対策を実装するためのフレームワークとプラクティスを提供します。

クラウドセキュリティアーキテクチャは、実際の建物を守るための設計図のようなものです。アクセス制御、監視システム、緊急時の手順など、必要なセキュリティ対策に加え、誰がどの区域にどのような条件でアクセスできるかを定める包括的なポリシーを示します。

同様に、クラウドでは、データ、アプリケーション、インフラを保護するために必要なセキュリティ制御、ポリシー、手順をセキュリティアーキテクチャが定義します。

クラウドセキュリティアーキテクチャには、次の要素が含まれます。

• クラウドの利用を統制する文書の作成とポリシー、ルール、プロトコルの策定

• 適切なセキュリティツールとソリューションの選定

• セキュリティの管理、監視、対応方法を定めるワークフローの確立

つまり、堅牢なクラウドセキュリティアーキテクチャは、効果的なクラウドセキュリティの土台です。

クラウドコンピューティングのセキュリティアーキテクチャの重要性

クラウド環境の管理には、クラウドセキュリティアーキテクチャが欠かせません。適切なクラウドセキュリティアーキテクチャがなければ、従来のセキュリティソリューションではクラウド環境への脅威に対処できず、組織はリスクにさらされます。

セキュリティ計画なしにクラウドへ移行すると、機密データや重要なアプリケーションが脅威にさらされる可能性があります。また、クラウド環境の保護に複数のソリューションが必要となり、セキュリティチームの負担が増えるだけでなく、全体の可視性が低下し、脅威や脆弱性につけ込まれる隙が生まれます。

クラウドセキュリティアーキテクチャにより、クラウドコンピューティングやクラウド環境を導入する組織は、セキュリティ計画を整え、データと重要なシステムの保護に取り組めます。

クラウドセキュリティアーキテクチャの種類

企業が設計するクラウドセキュリティアーキテクチャの種類は、利用するクラウドサービスによって異なります。セキュリティに万能な方法はありません。そのため、組織は利用しているクラウドコンピューティングの種類を確認し、最適な戦略とアーキテクチャを判断する必要があります。

クラウドセキュリティアーキテクチャを検討する際は、次の4つの導入モデルを考慮します。

パブリッククラウド：共有インフラの活用

パブリッククラウドサービスは、Amazon Web Services (AWS)、Microsoft Azure、Google Cloud Platform (GCP)などのサードパーティプロバイダーが提供します。共有インフラを利用するため、複数の契約者が同じサービスを使います。大きな建物の一室を借りるように、基盤となるインフラを他の利用者と共有します。

プロバイダーは、データセンターやコアネットワークなど、物理インフラの保護を担います。一方、「テナント」である利用者は、主に自分の部屋の中のセキュリティに責任を負います。クラウドでは、ユーザーアクセスの管理、データのコンプライアンス要件への適合、そして何よりデータ自体の保護がこれにあたります。

プライベートクラウド：専用の環境

プライベートクラウドは、独立した一軒家を所有するようなものです。自社のデータセンター（オンプレミス）でホストする場合も、サードパーティプロバイダーが自社専用に管理する場合も、クラウドサービスは組織だけで利用します。このモデルは環境とセキュリティをより細かく制御できるため、厳格なコンプライアンス要件や機密データを抱える組織に特に適しています。

制御性が高まる一方で、多くの場合、責任も増えます。プライベートクラウドの構成によっては、インフラからアプリケーション、データまで、セキュリティスタックのより広い範囲を管理することになります。

ハイブリッドクラウド：両方の利点を活用

ハイブリッドクラウドは、自宅と賃貸マンションを組み合わせるようなものです。プライベートクラウドとパブリッククラウドのサービスを組み合わせることで、パブリッククラウドの柔軟性と拡張性を活用しながら、機密データや重要なアプリケーションをプライベートインフラ内に保管できます。

ハイブリッド環境では、2つの異なる環境にまたがってセキュリティを管理するため、複雑になることがあります。シームレスに保護するには、プライベートクラウドとパブリッククラウドの両方をカバーする統一されたセキュリティ戦略と、一貫したポリシーが不可欠です。

マルチクラウド：クラウド環境の多様化

マルチクラウド環境は、複数のパブリッククラウドプロバイダーのサービスを利用し、異なる建物に複数の部屋を持つようなものです。コストの最適化、ベンダーロックインの回避、各プロバイダーの優れたサービスの選択などのメリットがあります。

ただし、各パブリッククラウドプロバイダーは、それぞれ独自のセキュリティポリシー、ツール、コンプライアンス対策を採用しています。そのため、各プロバイダーのセキュリティ環境を理解し、管理する必要があります。プロバイダーが自社のインフラセキュリティを担う一方で、すべてのクラウド環境にわたるデータ保護、アクセス制御の設定、暗号化の一貫した管理は、チームの責任です。

クラウドセキュリティアーキテクチャの主要な要素

クラウドサービスのメリットを最大限に引き出すには、堅牢なクラウドセキュリティアーキテクチャを構築する必要があります。包括的で強固な戦略を実現するには、次の主要な要素を組み合わせます。

可視性

暗闇の中で家を守ろうとする状況を想像してみてください。侵入者がどこにいるのか、どのような脆弱性があるのか分かりません。だからこそ、クラウドセキュリティでは可視性が不可欠です。クラウド環境やサービス全体で何が起きているかを、常に漏れなく把握することが重要です。これを実現するには、クラウドセキュリティポスチャ管理（CSPM）ソリューションなどのツールを導入し、セキュリティのベストプラクティスやコンプライアンス基準に適合しない設定がないかを継続的に監視します。これにより、脅威や脆弱性を事前に検出・特定し、リスクの優先順位を付けられます。

アイデンティティおよびアクセス管理

IAMはクラウドセキュリティの要です。適切なユーザーに、適切なリソースへの必要なレベルのアクセスだけを許可します。これは最小権限の原則に従い、ユーザーにタスクの実行に必要な最低限の権限のみを付与することで実現します。多要素認証（MFA）では、パスワード以外の認証情報も要求し、セキュリティをさらに強化します。ロールベースのアクセス制御（RBAC）では、個々のユーザーではなく職務に基づいて権限を割り当てることで管理を簡素化します。ゼロトラストアーキテクチャや特権アクセス管理（PAM）などの概念は、ユーザーやデバイスを本質的に信頼できるものと見なさず、特権アカウントのアクセスを厳密に制御することで、IAMをさらに強化します。

データ保護

クラウドでは、データが保護すべき最も価値のある資産であることが少なくありません。データ保護では、ライフサイクル全体を通じて機密情報を守る多層的なアプローチを実装します。これには、強力な暗号化アルゴリズムを使用して、保存中（「at rest」）と転送中（「in transit」）のデータを暗号化することが含まれます。データ損失防止（DLP）対策は、機密データが管理外へ流出するのを防ぎます。データ分類は、データの種類ごとの機密性を把握し、適切なセキュリティ制御を適用するうえで重要です。また、データの損失や災害に備えて、事業継続を確保するバックアップと復旧の戦略を策定します。複数の地域で事業を展開している場合は特に、データの主権や保管場所に関する要件も考慮しましょう。

脅威の検出と対応

強力な予防策を講じていても、脅威が発生する可能性はあります。セキュリティ情報イベント管理（SIEM）システムを使って、不審なパターンや異常を特定し、対応しましょう。クラウドワークロード保護プラットフォーム（CWPP）も、さまざまな脅威検出ツールを用いて、特定のワークロードを狙う脅威を検出します。ただし、検出は対策の半分にすぎません。セキュリティインシデント発生時の対応手順を定めた包括的なインシデント対応計画も同様に重要です。この計画には、明確な役割と責任、コミュニケーションプロトコル、封じ込め、根絶、復旧の手順を盛り込む必要があります。

ガバナンス、リスク、コンプライアンス

業界のベストプラクティスや関連規制（SOC 2、HIPAA、GDPR、PCI DSSなど）に準拠した明確なセキュリティポリシーと手順を策定し、セキュリティとコンプライアンスの基準を維持します。クラウドセキュリティポスチャ管理（CSPM）ツールを活用すれば、コンプライアンスを継続的に監視し、定められたセキュリティ基準からの逸脱を特定できます。リスク軽減プロトコルを導入し、潜在的なセキュリティリスクの特定、評価、対処を行います。最後に、定期的なセキュリティ監査を実施して、セキュリティ制御の有効性を検証し、改善点を特定します。

Infrastructure as Code（IaC）のセキュリティ

インフラの構築プロセスの初期段階からセキュリティを組み込むことで、設定ミスを防ぎます。この「シフトレフト」アプローチにより、クラウド環境への設定ミスや脆弱性の混入を防止できます。

ネットワークセキュリティ

クラウドでは従来のネットワーク概念の一部が抽象化されますが、ネットワークセキュリティは依然として重要です。クラウドネイティブのファイアウォールや侵入検知・防止システム（IDPS）を導入し、クラウド環境内およびクラウドとオンプレミスリソース間のネットワークトラフィックを保護しましょう。これらのツールは、ネットワークアクセスの制御や悪意のある活動の特定に役立ちます。仮想プライベートネットワーク（VPN）は安全な通信チャネルを確保し、安全なアプリケーションプログラミングインターフェース（API）は、クラウドサービスやデータにアクセスするための主要な窓口となります。

自動化

自動化は、効率を高め、セキュリティ対応を迅速化する鍵です。脅威の検出、対応、修復などの反復作業を自動化することで、効率と対応速度を高められます。たとえば、侵害されたインスタンスの隔離、脆弱性へのパッチ適用、セキュリティ設定の適用を自動化すれば、セキュリティインシデントの影響を大幅に軽減できます。

クラウドセキュリティアーキテクチャの原則

クラウドセキュリティアーキテクチャには、完全性、可用性、機密性という3つの基本原則があります。

• 完全性：データとシステムの完全性。データやシステムの正確性と一貫性を維持し、データの改変を防いでシステムの信頼性を保ちます。完全性を監視することで、不正アクセスや悪意ある変更、誤操作による変更・削除を防ぎ、システムを脆弱性のない状態に保ちます。

• 可用性：認可されたユーザーが、クラウドのリソースやデータに安定して継続的にアクセスできるようにします。冗長性の実装、ダウンタイムの最小化、サービス関連の攻撃への対策により、サービスの中断を抑えます。

• 機密性：機密データを不正アクセスから保護します。アクセス管理制御と最小権限の適用、暗号化、データマスキングなどの手法を用いて、クラウド上のデータやリソースへのアクセスを認可されたユーザーとデバイスのみに制限します。

クラウドセキュリティアーキテクチャにおける責任共有

パブリッククラウドでは、セキュリティはお客様とクラウドサービスプロバイダー（CSP）の双方が担います。これを責任共有モデルと呼び、セキュリティのどの側面を誰が担うのかを明確に定めています。CSPは、物理データセンター、ネットワーク、仮想化レイヤーなど、基盤となるインフラストラクチャのセキュリティ、つまりクラウド自体のセキュリティに責任を負います。基盤サービスの安全性を確保するのもCSPの役割です。

一方、お客様はクラウド内のセキュリティ、つまりクラウドに導入して設定するすべてのものに責任を負います。通常、データ、アプリケーション、一部のモデルにおけるオペレーティングシステム、ネットワーク構成、アクセス制御、関連規制への準拠などが含まれます。

この責任分担を理解することは、安全なクラウド環境の構築に不可欠です。マルチクラウド環境を利用するお客様は、環境ごとの責任共有に特に注意する必要があります。

（注：これは簡略化した例です。実際の責任分担は、次に説明する利用中のクラウドサービスモデルによって異なります。）

サービスモデル別のクラウドセキュリティアーキテクチャ

クラウドセキュリティアーキテクチャは、企業が利用するクラウドサービスの種類によって異なります。主なクラウドサービスモデルは次の3つです。

• Infrastructure as a Service（IaaS）：ベンダーがクラウド上でコンピューティングインフラストラクチャとリソースを提供します。ウェブサイトやアプリのホスティングなどに利用できます。

  • 例：Amazon EC2、Google Compute Engine、Microsoft Azure Virtual Machines。

• Platform as a Service（PaaS）：ベンダーがクラウド上でプラットフォームをホストし、アプリケーションの開発、実行、管理に利用できるようにします。

  • 例：Microsoft Azure App Service、Google App Engine、AWS Elastic Beanstalk。

• Software as a Service（SaaS）：ベンダーがクラウド上でアプリケーションとそのインフラストラクチャをホストし、利用者に提供します。

  • 例：Microsoft 365、Google Workspace、Salesforce。

IaaS、PaaS、SaaSに応じたクラウドセキュリティアーキテクチャの適応

責任共有モデルでは、サービスモデルに応じて、お客様とサービスプロバイダーのセキュリティ責任の範囲が変わります。

• IaaS：責任の大部分はお客様が負います。オペレーティングシステム、アプリケーション、ミドルウェア、データを管理する必要があります。サービスプロバイダーは基盤となるインフラストラクチャを管理します。

• PaaS：プロバイダーの責任範囲が広がります。お客様はアプリケーションとデータを管理し、サービスプロバイダーはオペレーティングシステム、ミドルウェア、ランタイム環境を含む基盤インフラストラクチャを管理します。

• SaaS：責任の大部分はプロバイダーが負います。お客様はアプリケーションを利用し、プロバイダーがインフラストラクチャ、オペレーティングシステム、アプリケーションソフトウェアを管理します。

責任を共有している場合でも、セキュリティの抜け漏れや可視性の欠如を防ぐため、組織がクラウドセキュリティアーキテクチャを維持し、適応させることは重要です。プロバイダーがすべてのセキュリティに責任を負うと思い込んだり、アーキテクチャを更新せずに新しいサービスモデルを導入したりすると、深刻なセキュリティ問題や脅威の悪用につながる可能性があります。

クラウドセキュリティアーキテクチャを脅かす5つの脅威

クラウドセキュリティアーキテクチャの構築では、クラウド環境における脅威への備えが重要です。よくあるクラウドセキュリティの脅威には、次のようなものがあります。

1. 設定ミス：クラウド環境のセキュリティ設定が適切でないと、脆弱性やデータの露出につながる可能性があります。デフォルトの認証情報の使用、過度に広いアクセス権限、脆弱性へのパッチ未適用などが含まれます。

2. アカウント乗っ取り：攻撃者や悪意あるユーザーがユーザーの認証情報を入手することです。フィッシング攻撃、パスワードリスト攻撃、脆弱性などを通じて発生する可能性があります。機密データへのアクセス、サービスの妨害、クラウド環境内でのラテラルムーブメントなどに悪用されることがあります。

3. 安全でないAPI：APIはアプリと外部システムをつなぐもので、クラウドリソースの管理によく利用されます。安全でないAPIは、攻撃者による機密データや機能への不正アクセスにつながる可能性があります。インジェクション攻撃を受けるおそれもあります。

4. サービス拒否（DoS）攻撃：クラウドサービスが不正なトラフィックで過負荷になり、認可されたユーザーがサービスを利用できなくなることです。組織に大きな混乱や経済的損失をもたらす可能性があります。

5. 内部脅威：クラウド環境の認可されたユーザーが、誤って、または意図的に悪意ある行為を行うことです。データ侵害、設定ミス、経済的損失などにつながる可能性があります。

このリストは網羅的なものではありませんが、よくある脅威を把握することで、より堅牢なクラウドセキュリティアーキテクチャの構築に役立ちます。また、攻撃者や脅威の変化に備えて、将来のセキュリティ問題の予防や検知にも役立ちます。

クラウドセキュリティアーキテクチャを評価する5つのステップ

既存のクラウドセキュリティアーキテクチャがある場合も、設計中の場合も、セキュリティ戦略を継続的に評価することが重要です。定期的な評価は、脆弱性の特定や新たな脅威への適応に役立ちます。クラウドセキュリティアーキテクチャの有効性を確認し、改善点を見つけるには、次の5つのステップに従いましょう。

1. 資産を特定してマッピングする。クラウド環境のセキュリティを把握するため、環境内にあるすべての資産を特定し、棚卸しします。資産には、仮想マシン、コンテナ、データベース、アプリケーション、API、データが含まれます。棚卸し後、セキュリティ制御に対応付け、潜在的な脆弱性を特定します。

2. コンプライアンスを確認する。クラウド環境も、業界規制やコンプライアンス基準を満たす必要があります。セキュリティ制御が基準を満たしていることを確認するには、自動化ツールと手動レビューを組み合わせるのが理想的です。

3. テストを実施する。クラウド環境を定期的にテストすることで、脆弱性や脅威を特定し、セキュリティ制御の有効性を確認できます。テストには、インフラストラクチャ、コンテナ、アプリケーション、設定をスキャンするツールを使った侵入テストや脆弱性評価などがあります。

4. 監視を自動化する。セキュリティの問題を発見し、対処するには、継続的なリアルタイム監視が不可欠です。自動監視ツールでユーザーのアクティビティを追跡し、セキュリティログを分析して、不審な挙動や活動を検知しましょう。

5. プロセスを見直し、改善する。プロセスを継続的に見直し、改善することで、ビジネスの目的や目標との整合性を維持できます。見直しと改善にあわせて、ポリシー、制御、計画を更新し、最適化しましょう。

Snykでクラウドアーキテクチャを保護

Snykは、開発チームが安全なインフラストラクチャとコンテナを最初から構築できるよう支援する、包括的なツール群を提供します。SnykのAI搭載プラットフォームは、アプリケーション、プラットフォーム、インフラストラクチャのセキュリティを開発プロセスに直接統合し、アプリケーションセキュリティとDevSecOpsガバナンスを支援します。この「シフトレフト」アプローチにより、セキュリティは開発の自然な一部となり、最後に立ちはだかる障壁ではなくなるため、開発が円滑になり、後から想定外の問題が発生するリスクも減らせます。

インフラストラクチャコードを保護するSnyk IaCや、コンテナを安全に保つSnyk Containerなどのツールを活用すれば、より安心して構築に取り組み、イノベーションに集中できます。セキュリティをシフトレフトしながら、安全なクラウド環境を構築する方法について詳しく知りたい方は、ホワイトペーパー「まずはシフトレフトから：安全なクラウドへの道のり」をダウンロードしてください。