クラウドセキュリティアーキテクチャ — セキュア・バイ・デザイン

Amazon Web Services（AWS）、Google Cloud（GCP）、Microsoft Azureといった主要なクラウドプラットフォームでは、何千人ものセキュリティ専門家が24時間体制でパブリッククラウドインフラを保護しています。しかし、クラウド環境を保護する責任を負うのは、クラウドプロバイダーだけではありません。クラウドプロバイダーには、自社のサーバー上で稼働するデータやワークロードを安全に保つ一定の責任がありますが、クラウドコンピューティングに伴うリスクの多くは、クラウドを利用する顧客が管理する必要があります。

従来のデータセキュリティモデルでは、組織がITインフラを全面的に管理していました。セキュリティ対策はネットワークの境界を強化することに重点が置かれ、ネットワーク内のユーザーやシステムはすべて信頼できるものと見なされていました。しかし、クラウド環境ではこのアプローチは通用せず、ハイブリッド環境やマルチクラウド環境ではさらに問題が深刻になります。この変化により、設計段階からセキュリティを組み込んだクラウドアーキテクチャが必要になっています。

この記事では、クラウドセキュリティアーキテクチャの意味と、クラウドネイティブ開発者にとって重要な理由を解説します。

クラウドセキュリティアーキテクチャが重要な理由

効果的なクラウドセキュリティアーキテクチャは、組織が迅速な開発とクラウドでの新機能の追加を続けながら、セキュリティ体制を維持するために重要です。現代の開発手法は進化が速く、クラウド環境は複雑なため、アプリケーションが本番環境で稼働するまでセキュリティ対策を待つことは現実的ではありません。クラウドセキュリティアーキテクチャのベストプラクティスを適用すれば、強固なセキュリティ体制を維持しながら、効率的にクラウドネイティブアプリケーションを構築できます。

クラウドセキュリティアーキテクチャの課題

綿密に設計されたクラウドコンピューティングのセキュリティアーキテクチャでは、次の課題を考慮する必要があります。

内部関係者による脅威

クラウド環境へのアクセス権を持つ従業員や関係者については、アクセスを許可する前に適切な審査とトレーニングを行い、アクセス権を厳格に管理する必要があります。クラウド環境は、悪意ある従業員による攻撃や、従業員の不注意による認証情報の窃取、設定ミスの影響を受けるおそれがあります。

コントロールプレーンの侵害

クラウドのコントロールプレーンとは、Amazon、Google、Microsoftなどのクラウドサービスプロバイダーが開発者に提供するAPI群で、日々利用するクラウド環境の設定や制御に使われます。攻撃者がクラウド環境に足がかりを得ると、狙うのはクラウドプロバイダーのAPIコントロールプレーンを操作できるAPIキーです。APIキーを使えば、環境に関する情報を収集し、横展開して、セキュリティツールの検知を回避しながらデータを見つけて持ち出すことができます。

DoS攻撃

サービス拒否（DoS）攻撃は、データやアプリケーションの可用性を脅かします。攻撃者がデータにアクセスしたり改ざんしたりできなくても、システムやデータを自社や顧客から利用できない状態にすれば、事業の中核となる業務を妨害できます。

DoS攻撃には一時的なものと永続的なものがあります。一時的な分散型サービス拒否（DDoS）攻撃では、攻撃者が大量のリクエストを送り、システムに過剰な負荷をかけます。ネットワークコンプライアンスポリシーを使って防御できます。永続的なDoS攻撃はハードウェアを損傷させてサーバーを使用不能にするため、技術者がシステムを一から物理的に再構築する必要があります。

顧客による管理

クラウドサービス上で稼働するデータやワークロードには、可視性と制御に関する課題があります。クラウドプロバイダーは、自社クラウドで制御を適用する方法について、詳細な情報を常に提供しているとは限りません。そのため、顧客の社内統制がクラウド環境の統制にそのまま適用できない場合があります。その結果、社内デバイスやネットワーク、クラウドリソースで異なる統制が混在し、可視性が低下して、侵害やデータ損失のリスクが高まるおそれがあります。

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

現代のクラウドプロバイダーは、責任共有モデルに基づいて運用しています。プロバイダーと顧客は、それぞれが所有するクラウドの領域に責任を負います。一般に、クラウドプロバイダーはデータセンターの物理的なセキュリティをはじめとするバックエンドのセキュリティを担い、顧客はユーザーデバイスやアクセス制御を含め、クラウドサービスを安全に利用する責任を負います。

クラウドコンピューティングでよく使われる次の3つのモデルについて、責任共有の範囲を見てみましょう。

多くの企業が、各クラウドサービスプロバイダーの独自の利点を活かすため、複数のパブリッククラウドを利用しています。そのため、クラウドをまたいでアプリケーションやデータを監視・保護する責任がますます大きくなっています。

クラウドセキュリティアーキテクチャで考慮すべき重要な点

クラウドセキュリティアーキテクチャで特に考慮すべき点には、設計段階からのセキュリティ、クラウドネイティブアプリケーションのセキュリティ、シフトレフト、自動化、クラウドコンプライアンス、クラウドの可視性、マルチクラウド管理があります。

それぞれを詳しく見ていきましょう。

設計段階からセキュリティを組み込む

クラウドセキュリティアーキテクチャには、セキュリティ上の考慮事項を組み込み、ポリシーの設定ミスによって誤って回避されないようにする必要があります。たとえば、ID管理を一元化し、クラウドリソースへのアクセスごとにロールベースのアクセス制御を適用すれば、コントロールプレーンの侵害対策にも役立ちます。

クラウドネイティブアプリケーションのセキュリティ

アプリケーションをクラウドにデプロイするメリットの一つは、俊敏性とスケーラビリティです。クラウドセキュリティアーキテクチャでは、セキュリティツールや手法が迅速なリリースを妨げたり、デプロイプロセスの障壁になったりしないようにする必要があります。そうでなければ、開発チームや運用チームがセキュリティ手順を省略したり見落としたりする動機になってしまいます。

シフトレフト

シフトレフトは、現代的なアプリケーションセキュリティのアプローチです。アプリケーションが本番環境で稼働するまで待つのではなく、開発プロセスのできるだけ早い段階からセキュリティテストを組み込みます。DevSecOpsの実践者の50%以上が、ワークロードのデプロイに何らかの形でInfrastructure as Code（IaC）を利用していると回答しています。そのため、本番環境でアプリケーションが稼働するまで待つのではなく、開発中にアプリケーションとインフラの両方をできるだけ早く、頻繁にテストすることが重要です。

自動化

開発者とセキュリティチームが、クラウドネイティブアプリケーションやデータに対する脅威を自動で検出して対応できるよう、セキュリティアップデート、制御、設定はコードで自動化する必要があります。

クラウドコンプライアンス

規制当局は、クラウド上のデータやプロセスに関する法規制を強化しています。責任を確実に果たすには、クラウドセキュリティアーキテクチャに、政府の規制に加えて、業界標準や組織内の基準も組み込む必要があります。

クラウドの可視性

ハイブリッド環境やマルチクラウド環境では、可視性の確保が課題になります。従来のセキュリティソリューションでは、クラウドベースのインフラ全体にわたるセキュリティの監視と管理が難しいことが少なくありません。そのため、効果的なクラウドセキュリティアーキテクチャには、ハイブリッド環境やマルチクラウド環境の可視性を高める技術や手法が必要です。

マルチクラウド管理

組織では、独自の設定や組み込みのセキュリティツールを備えた複数のクラウドプロバイダーを利用するケースが増えています。マルチクラウド環境の管理は、すでに多忙な開発者やセキュリティチームの負担をさらに増やします。そのため、クラウドセキュリティアーキテクチャには、各プロバイダーのセキュリティソリューションを一元管理できる仕組みが必要です。

Snykがクラウド環境の保護に役立つ方法

クラウドはデータセンターと呼ばれることがありますが、実際にはソフトウェアです。かつてインフラだったものが今ではアプリケーションの一部となっているため、クラウドアプリケーションの保護には、IT部門や運用部門からアプリケーションセキュリティへの責任の移行が求められます。クラウドネイティブセキュリティは開発者から始める必要があります。開発者が、コードの安全性を確保しながら、ビジネス目標を達成するソフトウェアの提供に専念できるようにするためです。Snykは、アプリケーションの実行に使われるインフラやコンテナを開発者が保護するためのさまざまなツールを提供しています。

シフトレフトとDevSecOpsの原則

Snykのクラウドネイティブアプリケーションセキュリティプラットフォームは、アプリケーション、プラットフォーム、インフラのセキュリティを開発パイプラインに統合し、新たな脆弱性を継続的に監視します。このプラットフォームは、セキュリティチームが本番環境でバグを発見して開発チームに差し戻すような、負担の大きいレビューサイクルをなくし、DevSecOpsの実践を促進します。開発プロセスの初めからセキュリティを組み込めば、セキュリティチームが後から開発者に追加機能や監査を求める必要はありません。初日からセキュリティが組み込まれていると確認できるからです。

Snyk IaC

Snyk IaCを使えば、開発者はインフラ設定の記述・デプロイと同時に保護できるため、手間がかかりミスの起きやすい手動レビューをなくせます。ポリシー・アズ・コードのルールを標準搭載し、Open Policy Agent（OPA）を活用したカスタムルールも作成できます。

コンテナセキュリティ

Snyk Containerを使えば、開発中から本番環境までコンテナレイヤーを保護できます。ベースイメージの推奨やアップグレードを自動化し、脆弱性の解消を支援します。また、SnykとSysdigの最近のパートナーシップにより、実行環境におけるコンテナの脆弱性のスキャンと修正も可能になりました。