サイト内の現在位置

[Practical Cloud Security:ピックアップ解説] 第二章 データアセット管理と保護

NECセキュリティブログ

2020年6月11日

私が担当するブログでは、O'Reillyから出版されている「Practical Cloud Security new window[1](以下、本書)」の内容を要点解説という形で連載しています。
今回は前回 [2]の1章に続いて、2章「データアセット管理と保護」について要点解説していきます。次回の私のブログでは3章を解説予定です。

はじめに

データを保護するためには、最初にデータがどこにあるかを明らかにし、それを分類する必要があります。そうして初めて、どの分類のデータをどのように保護するかを検討することができます。
ここで、アセット(資産)管理という用語があります。本書ではこれをデータアセット管理とクラウドアセット管理の2つに分けています。
本書ではデータアセットを重要な情報と定義しており、これは例えば、顧客の名前や住所、クレジットカード情報、銀行の登録情報、データにアクセスするためのクレデンシャル情報などがあります。

クラウドアセットについてはクラウドにある管理・処理対象のデータや、サーバやコンテナのようなコンピューターリソース、オブジェクトストアやブロックストレージなどのストレージ、それからデータベースやキューなどのプラットフォームインスタンスと定義しています。

クラウド上にあるデータアセット管理の考え方はオンプレミスの場合と同じですが、クラウドではデータアセット管理に役立つ技術があります。
本記事ではクラウドにおけるデータアセット管理について説明した後、それらの保護方法について説明していきます。

なお、本記事(2章)ではデータアセット管理とその保護について議論します。クラウドアセット管理については3章の内容ですので、次回説明します。

クラウドでのデータアセット管理

まずはデータの一般的な分類方法の例について示し、そのあとにクラウドでのデータアセット管理方法について説明します。

データの分類方法の例

組織ごとにデータの分類の仕方は異なってくるとは思いますが、以下のデータ分類ルール(レベル)の例は分類を始める際の最初のルールとしてはシンプルで良いでしょう。

低(Low)

このカテゴリの情報は一般に公開されても、組織への影響はほとんどないので問題ありません。いくつかの例を示します。

  • サーバのパプリックIPアドレス
  • 個人情報やシークレットなどの攻撃者にとって価値のある情報を含んでいない、アプリケーションのログデータ
  • シークレットなどの攻撃者にとって価値のある情報を含んでいない、ソフトウェアのインストール資料

中(Moderate)

このカテゴリの情報は適切な秘密保持契約(NDA)なしに、組織外に公開すべきではありません。多くの場合(特に大きな組織では)、このカテゴリのデータは知る必要性がある場合だけ、組織内でのみ公開すべきです。ほとんどの組織では情報の大部分はこのカテゴリに分類されます。いくつかの例を示します。

  • 情報システムの設計についての詳細な情報
  • 個人情報
    攻撃者がフィッシングやプレテキスト攻撃(pretexting attacks。ソーシャルエンジニアリングの一種で、他人のふりをして被害者の個人情報を取得する)するのに有用です
  • 発注書や出張の払い戻しなどの定期的な財務情報
    これは例えば買収の可能性を推測するために使われるかもしれません

高(High)

この情報は組織にとって重要であり、この情報の公開は深刻な被害を引き起こす可能性があります。このデータへのアクセスは、何重ものセーフガードを適用して厳重に管理してください。いくつかの例を示します。

  • 将来の戦略についての情報、または競合他社にとってアドバンテージとなる財務情報
  • 企業秘密
    例えば非常に有名なソフトドリンクやフライドチキンのレシピなど
  • シークレット
    例えばクラウドインフラへのフルアクセスに使用するクレデンシャルなど
  • 顧客の財務情報など、センシティブな情報
  • 公開された場合に報道される可能性がある、その他全ての情報

法律と業界ルールはデータの分類方法に参考になります。例えば、EUのGDPRには個人情報の取り扱いについての多くの要求事項があります。そのため、この場合は全ての個人情報を"中"のリスクとして分類し、それに従って対策するかもしれません。

クラウドでのデータの識別と分類

クラウドでは利用者がストレージにデータを保存していれば、それを確実に利用者に知らせます(でないと利用料として課金できないので)。これは利用者がクラウドにデータを保存したままその存在を忘れることの予防策になっており、データアセット管理の助けになっていると思います。

また、データを保存するクラウドストレージなどのクラウドアセットにタグ付けすることで、細かなデータアセット管理ができます。タグはインベントリにあるリソースの分類や、アラートをあげる対象の選択など、いろいろな目的で使われます。例えば、個人情報を含む情報を識別するためにpii:yesやdatatype:piiのようなタグ付けができます。

タグ付けによるデータアセット管理の問題点は、組織内でタグ付けの命名規則が統一されないことです。そのため、タグのリストを作成しておき、組織内で複数のクラウドプロバイダにおいても統一したタグ付けが行われるようにしてください。

クラウドプロバイダの中には、タグがリソースに適切に適用されているかを自動的にチェックする機能を提供しているところもあります。この機能によって、タグ付けされていなかったり、誤ってタグ付けされているリソースを早期に発見し、修正することができます。
まずは、異なるクラウドリソースで、dataclass:high、regulation:gdprなど、データ関連のタグが適用されているようにしてください。

ほかにも、データの識別・分類に役立つクラウドサービスがあります。例えば、Amazon MacieはAmazon S3バケットにセンシティブなデータがないか発見するのに役立ちます。
どのようにデータを分類するにしても、それぞれの分類レベルと例を定義して記録するようにしてください。そして、データを生成・収集・保護する全ての人がその分類を理解していることを確認してください。

クラウドでのデータ保護

クラウドでのデータ保護はオンプレミスと同じものもありますが、クラウドプロバイダは利用者に対してより簡単・適切・安価にデータ保護の方法を提供しています。

暗号化

暗号化はデータ保護において確実な解決策です。
データには3つの状態があり、状態によって暗号化のアプローチが異なります。
- 転送中(ネットワークを流れている状態
- 使用中(CPUで処理されているか、RAMにある状態)
- 保存中(ディスクのような永続的なストレージにある状態)

本記事では保存中のデータの暗号化について説明します。

保存中のデータの暗号化

保存中のデータの暗号化は正しく実装しようとすると、最も複雑になる可能性があります。問題なのは暗号化の対象が多いため、暗号化されたデータを復号するのに必要な暗号鍵も多くなり、鍵の管理が大変になることです。

従来、高いセキュリティレベルが求められるオンプレミス環境では、暗号鍵の保存のためにHSM(Hardware Security Module)が使われていました。HSMは認証されていないアクセスに対する、論理・物理での保護を行います。HSMを使わないシステムでは暗号鍵が保存されている領域への物理的なアクセスは比較的簡単にできますが、HSMを使った場合、HSM(暗号鍵が保存されている領域)に対する分解などの物理的な不正操作があったときに、それを検知しHSM内部のデータを消去します。
ただし、HSMは高価なので、ほとんどのオンプレミス環境で導入は難しいです。

一方で、クラウド環境では、HSMや鍵管理システムのような先進的なテクノロジーが、あまり予算が無いプロジェクトでも手の届くものになりました。
クラウドプロバイダが、利用者の環境専用のHSMをオプションとして用意している場合もあります。別の選択肢としては鍵管理システム(KMS: Key Management Service)があります。

KMSはHSMを使ったマルチテナントサービスで、鍵を安全に保管できます。利用者はクラウドプロバイダのHSMと(HSMだけの利用ができない場合)KMSを信頼し、KMSが適切に鍵管理しないかもしれないリスクを負う必要がありますが、(だいたいうまくできない)自身で鍵管理するリスクと比べると、KMSはコストのほとんどかからない素晴らしいセキュリティ対策です。これによって、あまり予算が無いプロジェクトにおいても適切に鍵管理できる恩恵を受けられます。

それでは、KMSを正しく使うにはどうすればいいのでしょうか。これは少し複雑なものになっています。

鍵管理

最もシンプルな鍵管理のアプローチは鍵を生成し、データを暗号化し、鍵をKMSに入れ、そして暗号化されたデータをその鍵で暗号化されたことを説明したメモと共にディスクに保存することです。

しかし、このアプローチだとKMSで管理する必要がある鍵の数が多くなってしまいます。KMSで管理できる鍵の数には上限が設定されている場合があるので、KMSで管理する鍵の数はなるべく減らしたいところです。

そこで効率的な鍵管理のために、暗号鍵(encryption key)と、鍵暗号鍵(key encryption key)の2種類の鍵を使う方法があります。暗号鍵はストレージ内のデータなどを暗号化するための鍵で、鍵暗号鍵はこの暗号鍵を暗号化するための鍵です。暗号鍵は鍵暗号鍵で暗号化後、暗号鍵自身で暗号化したデータのすぐそばに保存される一方、鍵暗号鍵はKMSに保存・管理され、取り出されることはありません。データを暗号化・復号したいときは、HSM(KMS)上で、鍵暗号鍵で暗号鍵を復号する処理が行われ、復号された暗号鍵を使います。

実は鍵管理のほとんどを自分自身で行う必要はありません。多くのクラウドプロバイダでは、ストレージインスタンス用にKMS暗号化を有効にしている場合、ストレージサービスはデータを暗号化する暗号鍵を作成し、鍵暗号鍵でそれを暗号化します。もちろん利用者はこの鍵暗号鍵をKMSで管理できますし、暗号化された暗号鍵は暗号化されたデータと一緒に保存されます。このように鍵の暗号化と復号、ストレージ内のデータの暗号化と復号も自分で行う必要はありません。

暗号消去によるデータアセットの完全な破棄

クラウドではデータ管理の責任は常に利用者にあるので、クラウド事業者が物理メディアの破棄をNIST SP800-88に沿って実施していると表明しているとしても、自衛手段として利用者自身でデータの破棄を行うのがより確実だと思います。

クラウドで大量のデータを破棄(復元できないように)するには暗号消去(Cryptgraphic Erace)が有効です。暗号消去では、暗号化されたデータのみがディスクに保存されているようにします。そして、KMS上にある鍵暗号化鍵へのアクセスを無効化し、データを復元(復号)不可能にできます。また、ディスク上にある暗号鍵をワイプすることでも復元不可能にもできます。

アセット(資産)管理は守りたいものを保護するためのベースとなるステップなので、ここはしっかり押さえておきたいところですね。
本ブログが少しでもみなさんの役に立ち、安心・安全な社会に少しでも寄与することを願っています。

参考資料

執筆者プロフィール

宮崎 駿(みやざき しゅん)
セキュリティ技術センター セキュリティ実装技術チーム

社内のセキュア開発推進・自動化に従事。
システムを堅牢化し“衛る”実践力を競う「Hardening II SecurEach」グランプリ。「Hardening II SU」 MVV(Most Valuable vendor)賞受賞。
CISSP Associateを保持。