クラウド・セキュリティーとは

こんにちは、IBM CloudのNataraj Nagaratnamです。

アプリケーションをデプロイする場合、従来の方法では、データセンターや実行しているサーバーについての責任をすべてお客様が負うことになります。

クラウド・モデルでは、お客様とクラウド・プロバイダーで責任を分担します。責任共有モデルでは、セキュリティーを見直して、お客様とクラウド・プロバイダーの責任を明確にする必要があります。

alt

[Platform as a Service]

Platform as a Serviceを例に取ってみましょう。お客様はPaaSを使用してアプリケーションをビルドし、データをクラウドに移行し、ビルドしたアプリケーションをクラウド上で実行します。

alt

お客様にはアプリケーション、ワークロード、データを保護する責任があり、クラウド・プロバイダーには、プラットフォームのセキュリティーを管理する責任があります。

これでネットワーク面でのコンプライアンスとセキュリティーが維持されます。コンテナ、ランタイム、分離の管理という点から見ると、これは下層のプラットフォームです。したがって、お客様はプラットフォーム内に独自のスペースを所有しています。

[Infrastructure as a Service]

一方、ワークロードをクラウドに移行してInfrastructure as a Serviceを使用する場合、お客様が仮想サーバーを使用していれば、下層のハイパーバイザーはクラウド・プロバイダーが管理します。お客様がベアメタルを使用している場合は、オペレーティング・システム、実行したりデータを取り込む仮想サーバーから上層のすべてをお客様が制御できます。

alt

[Software as a Service]

したがって導入モデル、つまりIaaS、PaaS、SaaSのいずれを使用しているかを理解することが重要です。SaaSではクラウド・プロバイダーがすべてのアプリケーションとセキュリティーを管理し、お客様は取り込むデータを検討し、それに従って計画を立てます。

alt

これは非常に重要なことです。なぜなら、クラウドに移行するワークロードやデータのリスクとコンプライアンスを最終的に管理するうえで、お客様自身の責任を理解することにつながるからです。

[アーキテクチャー]

それでは、アーキテクチャーについて見ていきましょう。アプリケーションをビルド、移行、モダナイズする場合、まずはデータについて考えます。

対処すべきリスクやデータに関する問題。それが機密データか公開データか、あるいは個人情報が含まれた重要データか。こうした要因をすべて考慮し、セキュアなデータ・セキュリティー・アーキテクチャーを設計します。

[データの暗号化]

保存データの暗号化

保存データの暗号化も設定します。これによってデータは常に暗号化されます。Database as a Service、Object store as a Service、あるいはデータ保管用のブロック・ストレージなど、使用するサービスは問いません。

alt

プロ向けのキー管理

暗号化はアマチュア向けですので、プロ向けのキー管理について考えてみましょう。キーをより厳密に制御することで、責任共有モデルのコンテキストで言うと、自分のデータを所有し、完全に制御することができます。

キー管理では、機密データの処理にはBring Your Own Key(独自のキーの持ち込み)アプローチを使用できます。重要データにはKeep Your Own Key(独自のキーの保持)を使用できます。

alt

重要データにはKeep Your Own Key(独自のキーの保持)を使用できます。キーの制御の範囲と、キーの処理や暗号化/復号が実行されるハードウェア・セキュリティー・モジュールが重要です。制御の範囲が大きいほど、責任は大きくなります。

移動データの暗号化

次に、保存データと移動データの暗号化です。サービスからデータ・ストアやアプリケーションに送信中のデータや、通信中のAPI要求は移動データです。

alt

クラウド環境では、アプリケーションがいつデータを処理するかを考える必要があります。データはこのメモリーに保存されています。

alt

メモリー内のデータも含めて、ハードウェア・ベースのテクノロジーを使って、データを保護することができます。アプリケーションで使用中のデータや、メモリー内のデータを保護できます。

alt

キーのフル・コントロールによる総合的なアプローチで、保存中、移動中、使用中のデータを保護します。これにはBring Your Own Keyを使用できます。Keep Your Own Keyで管理範囲を広げると、さらに強化されます

alt

[アプリケーション]

アクセス権

データを提供するアプリケーションについては、アクセス権が必要なアプリケーションを確認するだけは不十分です。データ・アクセスは個々のニーズに基づいた唯一のものでなければなりません。

データ・サービスを誰にでも公開してはいけません。ネットワーク・アクセスであろうと、世界中からのデータ・アクセスであろうと、どのアプリケーションにアクセス権が必要か、クラウド・アプリケーションを実行するためにどのユーザーが、データにアクセスする必要があるかを正確に把握してください。

セキュリティー

アプリケーション面でのセキュリティーでは、脆弱性がないことを確認するためにスキャンを実行します。これにはAppSec、アプリケーション・セキュリティー・アプローチを使用します。アプリケーションを本番にデプロイする前に、動的または静的スキャンを実行します。

alt

クラウド・ネイティブ・アプローチ

クラウド・ネイティブ環境では、コンテナ・イメージをデプロイするので、デプロイの前にそのイメージをスキャンして脆弱性を確認します。また、本番では常に保護されたイメージだけが使用されるように、ポリシーを設定します。

脆弱性があっても、クラウド環境ではシステムにパッチを適用する必要はありません。新しいコンテナを起動すればいいだけです。これがクラウド・ネイティブ・アプローチの利点です。あらゆるステップにセキュリティーが組み込まれています。

したがってお客様は、コンテナ・レベルでビジネス・ロジックを提供するアプリケーションを、保護するだけでよいのです。

alt

[ユーザーからのアクセス]

識別情報

ユーザーからのアクセスがあった場合、誰がどこからアクセスしているかを識別して、アクセスを管理します。ここで使用するのが識別情報です。サービスやユーザーの識別情報に基づいてユーザーの身元や、サービスの内容を確認し、それによってアプリケーションや、データへのアクセス制御を管理します。

alt

ネットワーク・アクセス

ネットワーク・アクセスという点では、許可されたユーザーだけがアクセスできるようにする必要があります。侵入者がクラウド内のアプリケーションやデータにアクセスできないよう設定しておく必要があります。Webアプリケーション・ファイアウォール、ネットワーク・アクセス制御により、サービス妨害、分散型サービス妨害から保護します。これらのネットワーク保護にもインテリジェンスを組み込みます。

alt

識別情報とネットワークはどちらも重要です。基本的に、お客様はデータを保護しており、アプリケーションへのアクセスや、クラウドにデプロイしたワークロードやデータを管理する必要があります。

alt

[セキュリティー・モニタリング]

継続的なセキュリティー・モニタリングによって、どの時点でもポリシーを順守していることを確認し、対処すべき脅威を監視する必要があります。セキュリティーおよびコンプライアンスの態勢を管理するためのアプローチとツール・セットを備えておくことが非常に重要です。

洞察の取得

そのために態勢、コンプライアンス、脅威に関する洞察を取得します。情報はデプロイメント環境から収集できます。例えばセキュリティー・イベント、監査ログ、ネットワークまたはシステムからのフロー・ログなどです。これらの情報から態勢、コンプライアンス、脅威の現状を把握できます。

alt

実用的なインテリジェンス

重要なのは洞察の取得だけではありません。問題を修正するための実用的なインテリジェンスも必要です。例えばデプロイしたコンテナ・イメージに脆弱性が見つかった場合、コンテナを再起動し、問題を修正して新しいコンテナを起動します。

alt

疑わしいネットワークIPアドレスからのアクセスがあった場合はそれをブロックします。したがって、可視性や洞察を得てそれを実用的なインテリジェンスや、修正に転換する能力が非常に重要です。

[DevOps]

従来のやり方

次はDevOpsについて見ていきましょう。DevOpsとは開発と運用を意味します。アプリケーション・チームが設計、アーキテクチャー、コーディングを担当し、セキュリティーと管理は企業のセキュリティー・チームに丸投げする、というのが従来のやり方です。これを見直さなければなりません。

SecDevOpsアプローチ

開発と運用だけでなくセキュリティーについても、後から対処するのではなく事前に考慮しておく必要があります。これがアプリケーションをビルド、管理、実行するためのSecDevOpsアプローチです。

alt

セキュアなデザイン

セキュリティーはライフサイクル全体に組み込む必要があります。これを「シフト・レフト」と呼び、セキュリティーを管理するだけでなくプロセス全体を前倒しします。それにはセキュアな設計が必要です。

alt

計画や設計の段階で、書き込むデータの種類、分類レベルは何か?ビルドするアプリケーションは何をするのか?コンテナ・ベースかどうか?移行するのはワークロードかなどを検討します。

そして計画、設計に必要な統合を明確にし、ビルドするときには、ビルド・プロセスの一環としてセキュリティーを組み込みます。こうしてセキュリティーに対応したアプリケーションを実現します。例えば、重要データを暗号化する場合、データ・ストアにデータを保存する前にアプリケーションでそのデータを暗号化します。

セキュアなビルド

ビルドにもセキュリティーを組み込みます。そしてセキュリティーを管理します。

alt

SecDevOpsの一環としてセキュアな設計を行い、アーキテクチャーを構築したら、それを次に渡してセキュアなアプリケーションをビルドし、セキュリティーをデプロイおよび管理します。これを継続的に行うことで閉じたループが形成されます。

alt

脅威の拡大に伴って問題が見つかったら、アプリケーションを修正または再設計するか、特定の機能を再実装する必要があります。

ご覧いただきありがとうございました。