クラウドセキュリティの課題

すべてはクラウドにかかっています。ローカルストレージではなくクラウドを選ぶことで、大幅なコスト削減が可能になり、大規模な運用でも非常に便利です。クラウドは、従来のデータセンターと比べて、市場投入までの時間短縮、コスト削減、レジリエンス、グローバル展開、セキュリティ、クラウドプロバイダーによるイノベーションなど、大きなメリットをもたらします。

しかし、クラウドコンピューティングには固有のセキュリティ上の問題やリスクも伴い、99%の企業にとって重要な懸念事項となっています。クラウドセキュリティの問題や特有の課題について詳しく解説します。また、セキュリティ対策を測定可能な形で改善し、クラウドの脅威を防ぐためのベストプラクティスも紹介します。

クラウドでホストされるインフラストラクチャによって、従来とは大きく異なる新たなセキュリティ上の懸念が脅威モデルに加わります。クラウドセキュリティに取り組むには、組織が責任共有モデルにおける自らのセキュリティ責任を深く理解するとともに、クラウドでプロビジョニングされるリソースの利用拡大によって複雑化し、変化し続ける攻撃対象領域を適切に把握する必要があります。設計段階からセキュアなクラウドアーキテクチャを構築することが、安全なクラウド利用の鍵となり、攻撃対象領域と侵入成功時の被害範囲を最小限に抑えます。

クラウドセキュリティには新たなアプローチが必要ですが、従来の情報セキュリティの基本原則は今も変わりません。組織には、重要な情報の機密性、完全性、可用性を維持する責任があります。この3要素を実現するには、クラウドセキュリティ特有の課題を理解することが重要です。

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

クラウドセキュリティとは、自社環境を隅々まで把握し、その情報を攻撃者に渡さないようにすることです。機密性の高いクラウドデータを保護するには、データの保存場所やアクセス方法を把握し、攻撃者が情報の探索、横展開、データ窃取に悪用するクラウドアーキテクチャの隙をなくす必要があります。

データは「新たな石油」と呼ばれることがあります。それほど価値のあるものです。顧客データ、医療データ、事業計画、財務情報など、さまざまな個人情報が含まれている可能性があります。プライバシー侵害が起きれば、顧客の信頼を失い、罰金や訴訟に直面するだけでなく、予期せぬ損失や問題につながることもあります。

セキュリティ上の主な課題11選

規模を問わず多くの組織が何らかの形でクラウドコンピューティングを導入しており、成長に伴ってクラウドサービスの利用範囲を拡大する可能性もあります。そのため、設定ミスなどのクラウドセキュリティ脅威を最小限に抑えるアーキテクチャを導入することが重要です。クラウドセキュリティは誰にとっても重要であり、セキュリティ体制の構築や既存体制の強化に、早すぎることも遅すぎることもありません。

1. レガシーシステム

2. コンテナワークロードのセキュリティ

3. データ侵害

4. 設定ミスと変更管理

5. クラウドセキュリティアーキテクチャ

6. オープンソース

7. アイデンティティ、認証情報、アクセス管理

8. 規制コンプライアンス

9. セキュリティ対策が不十分なAPI

10. 内部脅威

11. 社内の専門知識不足

1. レガシーシステム

クラウドセキュリティを実現するには、エンジニアリングチームがクラウドネイティブなセキュリティツールを導入し、クラウドを前提としたアーキテクチャを支える専用ポリシーと人員を整える必要があります。クラウドインフラストラクチャに従来のツールを無理に適用するのは得策ではありません。ネットワーク監視やファイアウォールなどの従来型ツールは、通常クラウドに対応していないためです。クラウド環境を十分に保護できず、侵害のリスクが高い状態が続く可能性があります。

その理由は、明確なネットワーク境界が存在しないため、クラウド環境ではレガシー環境とは異なる脅威モデルが適用されるからです。たとえばレガシーインフラストラクチャでは、ファイアウォールや物理的なネットワークトポロジーによって、ネットワークの内側と外側が明確に区別されています。内部リソースを外部トラフィックに公開するには、ファイアウォールを含むネットワーク機器に明示的な設定を行う必要があり、特定のルーティングトポロジーにも依存します。

一方、クラウドリソースはプロビジョニング直後から、一般公開される設定にできてしまいます。安全な状態を維持するには、ゼロトラストポリシーを採用する必要があります。エンジニアリングチームは、どのノードも侵害されている可能性があると想定し、ネットワークアーキテクチャ上の位置にかかわらず、あらゆる通信に認証と暗号化を適用すべきです。また、ノードが侵害されている可能性を前提とするなら、侵入時の被害範囲も評価しなければなりません。攻撃者は、アクセスしたリソース上のAPIキーを利用してクラウドのコントロールプレーンを侵害し、情報を探索し、横展開し、検知されずにデータを窃取するためです。

2. コンテナワークロードのセキュリティ

クラウドで実行されるアプリケーションやワークロードは、ワークステーションやベアメタルサーバーの時代から大きく進化しました。Webアプリケーションは主要なソフトウェア配布方法の一つであり、コンテナはその実行環境として最も広く利用されるプラットフォームの一つになっています。本番ワークロードの78%超がコンテナとしてデプロイされています。

コンテナそのものに加え、Kubernetesなどのコンテナオーケストレーションツールは、アプリケーションをスケールさせる強力な手段を組織にもたらす一方で、さらなる複雑さとセキュリティ上の懸念も生み出します。

コンテナは、従来のアーキテクチャにはほとんど類例のない、新たなクラウドセキュリティ課題の一つです。Dockerエンジン上で実行されるものなど、コンテナの多くは、サードパーティの公開リポジトリから取得したベースイメージを使用して構築されます。こうしたベースイメージは古くなっていたり、悪意ある攻撃者がアップロードした、正規イメージを装う侵害済みのバージョンだったりする可能性があります。

こうした侵害の可能性から、開発ライフサイクルとツールチェーン全体で機能するセキュリティツールの必要性が明らかになります。本番環境でこのような脆弱性が見つかった場合、組織はすでに侵害されている可能性があります。

3. データ侵害

データ侵害は、セキュリティインシデントの上位に常に挙げられます。頻繁に報道されており、最先端のクラウドを利用する顧客でさえ被害に遭うことがあります。

データには価値があり、意図しない情報漏えいが多くの影響をもたらすことを理解することが、被害を防ぐうえで重要です。そのため、常にデータを暗号化し、十分にテストされた強固なインシデント対応計画を整えておくことが大切です。データの入出力の完全性を確保する仕組みも欠かせません。リスクを軽減するため、組織はセキュリティ対策に優先順位を付け、文書化する必要があります。

前述のとおり、データ侵害は企業の評判に深刻な打撃を与えることがあります。Capital Oneで発生したクラウド設定ミスの後も、その影響が見られました。侵害を受けた企業は、注目度の高い訴訟に直面すると同時に、規制当局の厳しい目にもさらされる可能性があります。窃取された組織の個人識別情報や個人の医療情報が、闇市場で売られることさえあります。

4. 設定ミスと変更管理

すべての組織には、クラウドにどのようなデータを保存しているか、そのデータにどのユーザーやマシンがアクセスできるか、そして組織内とクラウドプロバイダーの双方でどの程度の保護が適用されているかを把握する責任があります。

実際のところ、数多くのセキュリティ対策を導入していても、チェックリストに沿った対策だけではクラウドデータを安全に保てません。クラウド環境は常に変化しており、設定ミスはデータ侵害につながる可能性があります。攻撃の実行に数分しかかからないケースもあります。調査対象となった組織の56%超が、設定ミスまたは既知の脆弱性に関するインシデントを経験しています。

設定ミスのリスクを最小限に抑えるには、厳格な変更管理システムを導入することをおすすめします。システムへの変更を申請、承認、検証し、記録する仕組みです。変更管理が不十分だと、クラウドの設定ミスや侵害につながる可能性があります。

ポリシー・アズ・コードも、設定ミスを防ぐ方法の一つです。セキュリティチェックを自動化できるほか、解釈、評価、適用のばらつきをなくし、すべての関係者が単一の信頼できるセキュリティポリシーを基準に運用できるようになります。また、人的ミスや時間のかかる手作業も削減できます。Open Policy Agentは、Netflix、Pinterest、CloudFlareなどの企業が利用・サポートする、ポリシー・アズ・コードのオープンソース標準として広く普及しています。

5. クラウドセキュリティアーキテクチャ

クラウドセキュリティアーキテクチャや戦略が整っていない組織は少なくありません。クラウドに移行する前に、自社がどのような脅威にさらされるのかを理解し、チームにクラウドセキュリティアーキテクチャの専門知識を備えることが重要です。クラウドセキュリティは、クラウド環境の設計段階で対処するのが最も効果的だからです。デプロイ前に、適切な移行手法と戦略を採用する必要があります。また、エンジニアリングチームはクラウドサービスのセキュリティプログラムを精査し、パブリッククラウドのセキュリティリスクを最小限に抑えるべきです。

第三者による監査を実施し、報告書を共有してもらう必要があります。また、クラウドプロバイダーの技術的なソリューションを補完するため、侵害発生時の報告条件も契約に盛り込むよう求めましょう。

6. オープンソース

文化、プロセス、パッケージのメンテナンス、さらには開発者向けツールの面での取り組みが、クラウドのオープンソースセキュリティエコシステム全体におけるセキュリティ体制と成熟度の向上を後押ししています。オープンソースのツール、プラットフォーム、コードをクラウドシステムに採用する際は、リスクを理解することが重要です。重要なリスクを把握すれば、組織のセキュリティ強化につながります。

オープンソースツールに伴う主なリスクの一つは、専任のサポートがない場合があることです。また、サポートが非公式で、十分でない可能性もあります。さらに、オープンソースコンポーネントの脆弱性は、オープンソースコミュニティや監視団体によって公表されることがよくあります。そのため、不要な調査や批判の対象になったり、セキュリティ攻撃にさらされたりする可能性があります。

7. アイデンティティ、認証情報、アクセス管理

また、企業には数百人から数千人のエンジニアが在籍する場合があるため、従業員の役割とニーズに応じてアクセス権を付与する必要があります。アクセス制御では、最小権限の原則を適用するとともに、データを安全に廃棄・削除するための手順とポリシーを定めることが重要です。

総じて、プロビジョニングとデプロビジョニングの問題、休眠アカウント、過剰な管理者アカウント、アイデンティティおよびアクセス管理（IAM）制御を回避するユーザーに対処するため、クラウド認証情報を継続的に監査、追跡、監視、管理することが重要です。

IAMは現代のクラウド侵害において中心的な役割を果たしており、そのリスクは人や人間によるアクセスだけにとどまりません。IAMは本質的にクラウド内のネットワークであり、クラウドリソースはIAMを使ってほかのクラウドリソースとやり取りします。コンプライアンス監査や多くのセキュリティツールでは検出されない、安全でないIAM設定を特定するため、クラウド環境におけるIAMの利用状況を重点的に評価する必要があります。また、開発者はInfrastructure as Codeの開発時に、安全でないIAM設定を検出するポリシー・アズ・コードのチェックを導入すべきです。

組織には、二要素認証の導入、厳格なクラウドIAM制御の遵守、APIキーの定期的なローテーション、未使用の認証情報の廃止も推奨されます。

8. 規制コンプライアンス

クラウドセキュリティ対策と同様に、企業はクラウドにおける規制遵守に関する責任分担を把握し、明確に定める必要があります。特に医療データや金融データを扱う場合は重要です。規制は数多くあり、常に変化しています。そのため、機密データを扱うクラウドサービスプロバイダーやアプリケーションが、該当する認証を取得し、規制に準拠していることを確認する必要があります。

クラウドを利用する組織が注意すべきデータ規制は、少なくとも4つあります。

• HIPAA：保護対象医療情報を処理する医療アプリケーションには、医療保険の相互運用性と説明責任に関する法律（HIPAA）に定められたプライバシーおよびセキュリティ規則が適用されます。HIPAAにより、医療関連事業者はクラウドプロバイダーから、この種のデータを保護するという保証を得る必要がある場合があります。

• PCI：Payment Card Industry Data Security Standard（PCI DSS）は、American Express、Discover、Mastercard、Visaなどの主要なカード決済システムのクレジットカードを取り扱う企業に適用されます。この基準はクレジットカード会社によって義務付けられ、Payment Card Industry Security Standards Councilが監督しています。クレジットカード詐欺の削減を目的として策定されました。

• 個人データ：消費者、従業員、パートナー、そしてほとんどあらゆる法人を特定できる情報が含まれます。個人データに関する法律を遵守するため、多くのデータ侵害規制では、組織にコンプライアンス状況の報告と、発生した侵害の公表を義務付けています。

• GDPR：EU域内の人々のデータ保護を強化するため、一般データ保護規則（GDPR）が施行されました。氏名、住所、写真、メールアドレス、銀行口座情報、ソーシャルネットワーキングへの投稿、医療情報、IPアドレスなどのデータは、EU域内のサーバーに保管し、管理する必要があります。企業はデータ侵害があった場合、本人に通知しなければなりません。

9. セキュリティが不十分なAPI

クラウドサービスには、API（アプリケーション・プログラミング・インターフェース）が伴います。通常、APIは利用者向けに十分なドキュメントが用意されています。しかし、組織側の設定ミスがセキュリティ侵害につながる可能性があります。また、クラウドサービスプロバイダーのドキュメントをサイバー犯罪者が利用して、脆弱性を特定・悪用し、機密データを盗み出すおそれもあります。

さらに、利用者向けに作成されたAPIドキュメントをサイバー犯罪者が使い、組織のクラウド環境から機密データにアクセスして持ち出す方法を特定・悪用する可能性もあります。

そのため、APIの適切な衛生管理を実践し、標準的なオープンAPIフレームワークを導入するとともに、APIキーの再利用を避けましょう。APIのセキュリティをテストし、適用される法律、法令、規制要件に準拠していることを確認してください。

10. 内部関係者による脅威

これはクラウドに限った問題ではありません。しかし、意図的か不注意かを問わず、現職・元従業員、請負業者、パートナーがデータ侵害やサービス停止を引き起こし、消費者の信頼を損なうことがあります。

内部関係者による脅威には、データの漏えい・盗難、認証情報の問題、人的ミス、クラウドの設定ミスなどがあります。こうした脅威に対処するには、セキュリティ意識向上トレーニングを実施し、設定ミスのあるクラウドサーバーを修正し、重要なシステムへのアクセスを厳格に管理する必要があります。

11. 社内の専門知識不足

これはおそらく、今日の組織が直面している、悪意のない内部関係者による最大の脅威です。また、この記事でこれまで取り上げてきた多くのテーマが、この問題に集約されています。

クラウドプラットフォームやAPIの設定ミスが、さまざまなデータ脆弱性につながることを忘れないでください。データ規制を理解し遵守できなければ、政府当局から厳しい措置を受けるだけでなく、評判を損なう可能性もあります。適切で文書化されたアクセス制御や変更管理の実践を怠れば、組織は内部・外部の脅威にさらされ、望まない世間の注目や訴訟を招くおそれもあります。

Snykでクラウドセキュリティの課題を克服

クラウドへの移行が広がる一方で、クラウドネイティブ戦略の導入後にセキュリティへの懸念が高まったと回答した組織は、約60%に上ります。

主要なクラウド攻撃や侵害の多くは、設定ミスによって悪用された、あるいはその影響が拡大したアプリケーションの脆弱性が組み合わさって発生します。だからこそ、開発チームとセキュリティチームは、クラウドネイティブアプリケーションを保護するためのベストプラクティスを理解することが重要です。

クラウドネイティブの専門家と同じ方法でアプリケーションを保護しましょう。Snykの開発者向けセキュリティソリューションは、最新のアプリケーションを安全に構築できるようにし、開発者がコードやオープンソースからコンテナ、クラウドインフラまで、アプリケーション全体のセキュリティを担い、構築できるよう支援します。