企業におけるAmazon Macieの利用戦略を考える

はじめに

西藤です。

AWSのクラウドを企業において利用する際には、一定の統制のとれた形での利用が求められます。

そのためには、たとえば、Amazon GuardDutyによる脅威検知を入れる、Security Hubによるセキュリティの統合管理体制を作るなど多層に仕組みを入れることが考えられます。

今回はそういった取り組みの一環として、Amazon Macieを企業で利用する上での検討事項について考えてみたいと思います。

Amazon Macieとは

まず、Amazon Macieについて簡単に確認します。

Amazon Macieは、Amazon S3バケットに保存されている機密データを検出し、分類するサービスです。

Amazon Macie では、機械学習とパターンマッチングを利用して機密データを発見し、データセキュリティのリスクを可視化して、そのリスクに対する自動的な防御を行います。

https://aws.amazon.com/jp/macie/

これにより、たとえば、「個人情報がS3に保存されていた」というような偶発的にS3バケットに保存された機密情報を検出し、セキュリティ体制の改善に役立てることができます。

AWS Organizationとも連携可能であり、組織内横断的に機密データの保持状況の可視化に活用できます。

今回はこのAmazon Macieを企業内で利用するに際して検討すべき観点を考えてみます。

観点１：企業内におけるセキュリティ対策との整合性

さて、タイトルにもあるように、Amazon Macieを企業で利用するに際して、まずどのような観点で検討を行うべきか考えてみます。

まずは、Amazon Macieに限らず、企業内におけるセキュリティ対策の考え方について検討します。

企業においては「オンプレミスかクラウド」、もしくは、"Amazon S3"のような「どのサービスを使うか」に限らず、ITシステムをリリースするに際してはレビューが行われることが多いことでしょう。（実際、私もこれまで従事してきたプロジェクトの中でそういったレビュー体制をお持ちのお客様を多数見てきました。）

そしてそのレビューの中には、当然セキュリティ観点でのレビューも含まれるはずです。

ITシステムがどのようなデータを扱っているか「データ分類」を行い、「外部に公開できない機密データである」などのようなデータ分類に基づいて、追加の保護策への投資を決定します。

たとえば、保護設定の確認、脆弱性対策、WAFの導入、脅威検知のための監視体制などを他のシステムよりも重要度を高めて実施する、と言ったことが考えられます。

つまり、機密データが格納される予定があるシステムには、それに応じたセキュリティ対策が実施されると言うことです。

Amazon Macieは想定外に機密データが保持されていたことを検出するのに効果が期待できます。

十分なセキュリティ対策が講じられており、さらに「機密データを保持することがわかっている」ような環境に対して、Amazon Macieを有効化するのは冗長になってしまう場合すらあります。

既存のセキュリティ対策と共存する戦略を考える必要があります。

観点２：Amazon Macieのスキャン対象

それを踏まえて、Amazon Macieでのスキャン対象を考えます。

Amazon Macieにおけるコストは、料金 - Amazon Macie _ AWS を参照することになりますが、スキャン対象となるデータ量に応じてコストが発生します。

つまり、組織内のS3バケットすべてにスキャンする、と言うのはコストを考えると時として現実的ではない場合があります。

では、Amazon Macieはどこに使うのが良いでしょうか？

ここでは

• 機密データを格納する予定のないS3バケット

を対象とすることにします。

こうすることで十分にデータ保護策が実施されているS3バケットには、Amazon Macieによるスキャンを行うことなく、コストを抑えることができます。

一方で、保護策が実施されていないS3バケットに対しては、Amazon Macieによるスキャンを行うことで、偶発的に機密データが保存されていないかを検出しリスクに備えることができます。

また、追加の保護策が投じられていないであろう、「開発」「検証」などの環境についても、検討が必要です。

• 偶発的に機密データが格納されることによるリスクを「開発」「検証」環境においても検出したいと言う判断のもと、Amazon Macieのコストを投じる

か、一方で、

• 外部公開されないように確実に担保できる運用ポリシーや仕組みが入っていれば、「開発」「検証」環境ではAmazon Macieを導入せず、コストを抑える

と言った選択肢からの判断になることでしょう。

機密データにまつわるトラブルは「想定外にデータが処理、格納されたこと」に起因するはずです。

機密データを保管する予定のなかった。ある意味、注意が抜けてしまいがちな環境に対して対象を絞って有効化することで、コスト観点でも効率的なスキャン体制を構築できるでしょう。

観点３：コスト見積もり

さて、コストの観点を踏まえて、すべての環境、すべてのバケットを対象にしないことでコスト最適化は図れそうです。しかし、だからと言って実際の企業ユースにおいてはそのままいきなり使えるわけではなく、利用前のコスト見積もりが求められることが多いでしょう。

ここでは、Amazon Macieのコスト見積もりの方法を考えます。

トライアル期間の利用

一番手っ取り早い方法として、トライアル期間の利用が考えられます。

Amazon Macieは初回利用時に30日間のトライアル期間が提供されています。

これにより一度実際に利用してみつつ、無料期間じゃなかった場合はどの程度のコストがかかったかを表示してくれるので、トライアル期間後にも利用を続ける際のコストを見極めることができます。

ただし、注意点としてはスキャン時のデータ量の上限があり、

• 「無料トライアル期間内にアカウントあたり最大 150 GB」

と言う記載がありますので、企業の規模によってはトライアルの枠だけでは実際の利用相当を試すことができない場合があります。

また、企業においては新しい仕組みを導入するに際して、事前にコストの見積もりを算出されていることが求められる場合も考えられます。

そのため、「一度無料期間で使ってみて、その間でコスト感を見極める」と言う戦略が取れません。見積もりを経て導入し、最初に行った見積もりとの差異を確認するためにトライアル期間を使うと言う位置付けになることでしょう。

そういった場合は、

次に記載するS3のStorage Lensを使った方法も併せて検討しましょう。

S3のStorage Lensを使ったコスト見積もり

組織内にどれだけのS3バケットと、その中に格納されたデータが存在するかを把握するための方法として、S3の"Storage Lens"による可視化が使えます。

Storage Lensを利用した組織内でのS3の利用状況の可視化については、以下の記事に任せますが、これを使うことで、組織内でのS3バケット数、保存されているオブジェクトのデータ量を把握できます。

Amazon S3 Storage Lens の紹介 — オブジェクトストレージに組織全体にわたる可視性を _ Amazon Web Services ブログ

そして、Storage Lensで得られた情報を元に、AWS Pricing Calculatorを使ってAmazon Macieのコストを見積もることができます。

AWS Pricing Calculator

このようにして、トライアル期間を使って実際の利用料の予測を確認することができない場合にも、Storage Lensを使ってコスト見積もりを行うことができます。

観点４：対象リージョン

Amazon Macieはリージョン単位で利用するサービスです。

そのため、AWS Organization連携している形にしていても、リージョンごとにその有効化の設定を行う必要があります。

冒頭の「機密データを格納する予定のないS3バケットを対象にスキャンする」と言う話を踏まえますと、「普段使いしていないリージョン」の方がスキャンするニーズがある場合もあります。

ただし、リージョンごとに有効化の判断と設定を行う必要があることを考えると、リージョンの数が増えることで管理コストが増えることになりますので、その辺りのバランスを考える必要があります。

なお、AWS Control Towerを使ってマルチアカウント管理を行なっている場合は、「リージョン拒否コントロール」を使うことで、特定のリージョンでのサービスの有効化を制限できます。

その仕組みを使うことで、

• 使う予定のないリージョンはControl Towerで無効化しておく（リージョンが無効化されていれば、そのリージョンでリスクが発生しない）
• Amazon Macieは無効化されていないリージョンでのみ有効化する

と言う形で、抜けのない体制を構築できるので、Macie以外のツールとの組み合わせで総合的な設計も考えることが求められます。

観点５：対象の識別子

Amazon Macieにおける機密データの検出は、AWSが提供するマネージドデータ識別子を使って行うことができます。

内容としては

クイックリファレンス_ Amazon Macie マネージドデータ識別子 - Amazon Macie

に記載されていますが、大きく4つのカテゴリがあり、

• 認証情報
• 財務情報
• 個人情報：PHI
• 個人情報：PII

となります。

「認証情報」は、AWSシークレットアクセスキーなどを検出します。

「財務情報」は、銀行口座番号などは各国固有のものとなっており、日本向けの情報はカバーされていませんが、クレジットカード番号についてはJapanese Card Bureau (JCB)も含めて各ブランドのクレジットカード番号が検出対象となっています。

そして、最後に「個人情報」のカテゴリがあり、たとえば運転免許証番号などが含まれているのですが、こちらは現在、日本向けに対応している識別子がありません。

そのため、日本国内においてはAmazon Macieをマネージドな形そのままで使うだけでは、「認証情報と、クレジットカード番号のみが検出できる」と言うことになります。

Amazon Macieのサービスの説明を見た時にどうしても「個人情報」を検出してくれることを期待してしまいますが、日本国内だとそこがカバーされていませんので注意が必要です。

たとえば、日本においても運転免許証には番号が付加されていますし、マイナンバーという制度もあります。しかし、そういった日本固有の識別子については、マネージドな識別子では検出できないため、要件に応じて、カスタムデータ識別子を作成することが求められます。

Amazon Macie でのカスタムデータ識別子の構築 - Amazon Macie

まとめ

以上、Amazon Macieを企業の組織内で利用する際の検討事項について考えてみました。

振り返りますと

• 「社内にてすでにあるセキュリティ対策と重ねて冗長な仕組みになってしまわないか」
• 「効果的にスキャンを行うために、対象の環境・バケットはどれにするべきか」
• 「運用を始める間に、どのようにコストの見積もりを行うか」
• 「どのリージョンで有効にするべきなのか」
• 「スキャン対象としたい識別子は何なのか」

といった考え方で利用時の設計をすると良いのではないでしょうか。

観点5にも書きましたが、特に日本国内ですと「個人情報（PII）」識別子が網羅的にカバーされておりませんので、Amazon Macieを使って何を実現するかという目標設定がより大切になってくると言えるでしょう。

本記事がその検討をする上での参考となれば幸いです。

sho