Amazon Web Services ブログ

Amazon FSx for Windows ファイルサーバーでエンドユーザーアクセスのセキュリティ通知機能を実装する

このブログはJaroslav Skrickij (Sr. Solutions Architect at AWS)によって執筆された内容を⽇本語化したものです。原⽂はこちらを参照して下さい。

AWSでは、セキュリティは最優先事項です。お客様のデータへのエンドユーザーのアクセスを記録することは、多くのお客様の内部セキュリティポリシーやコンプライアンスニーズを満たす上で重要な要素です。エンドユーザーアクセスの監査ログは、定期的なセキュリティ監査やセキュリティインシデントのフォレンジック調査に利用されます。しかしながら、お客様は新たに発生するセキュリティリスクを事前に評価し、悪意のあるユーザーが引き起こす可能性のある被害を軽減するために、不審なアクセスをほぼリアルタイムで知りたいケースもあります。データセキュリティ管理者は、共有ファイルストレージに繰り返し不正アクセスが発生した場合や、大量のファイルが予期せず削除された場合などに、迅速な対応を求められます。

ファイルアクセス監査が新たにサポートされたことで、エンドユーザーによるAmazon FSx for Windowsファイルサーバーファイルシステムへのアクセスをログに記録し、セキュリティやコンプライアンスの要件を満たすことができるようになりました。監査ログは、Amazon CloudWatch Logsに転送されるか、Amazon Kinesis Data Firehoseにストリームされます。お客様は、CloudWatch Logsの監査イベントを照会し、CloudWatchアラームやAWS Lambda関数をトリガーにして、ユーザーアクティビティをレポートすることができます。また、ログをAmazon S3にアーカイブしたり、SplunkやDatadogなどのAWSパートナーソリューションを利用して、イベントの監視やレポートを行うこともできます。

このブログでは、お客様がAmazon FSx for Windowsファイルサーバー上でファイルアクセス監査を設定し、ログをAmazon CloudWatch Logsに転送し、CloudWatchアラームを使用してほぼリアルタイムで不審なユーザーアクセスの通知をトリガーする方法を説明します。このソリューションは、不審なアクセス試行がベースラインを超えて増加したときに通知を受けるために使用できます。これは、ファイル共有全体、個々のフォルダ、または特定のファイルに対して設定することができます。このような通知を受けて、お客様は一定の時間内にログを調査し、このような増加の原因を理解し、適切な対応を取ることができます。

必要となるもの

環境の準備

まず、この新機能を紹介するために用意したインフラを見てみましょう。

図1: システムアーキテクチャ

 

図1に示すように、2つのアベイラビリティーゾーンにまたがるVPCがあり、2層のプライベートサブネットがあります。管理サーバーがあり、環境を設定したり、クライアントとしてAmazon FSxファイルシステムにアクセスするために使用しています。私はAWS Systems Manager Session Managerを使用して、インターネットに公開することなく安全にサーバーに接続しています。AWS Managed Microsoft ADは、2つのプライベートサブネットに展開しています。ジャンプサーバーとAmazon FSxファイルシステムの両方は、AWS.CORPというActive Directoryドメインのメンバーで、AWS Managed Active Directoryサービスに参加しています。fsxclientというActive Directoryユーザーを追加して、不正なアクセス行為をシミュレートします。上図のように、2つのアベイラビリティーゾーンにまたがるMulti-AZデプロイメントタイプを使用して、Amazon FSxファイルシステムを作成します。これでインフラストラクチャのセットアップは完了です。次に、監査プロセスがどのように機能するかを見てみましょう。

Amazon FSxでのファイルアクセス監査の有効化

Amazon FSxは、Amazon FSxコンソール、AWS CLI、またはAPIを使用して管理できる、ファイル、フォルダ、およびファイル共有上のエンドユーザーのアクセス監査をサポートします。ファイルアクセス監査の機能、サポートされているイベント、イベントログの宛先については、ドキュメントを参照してください。これらのログの送信先は、CloudWatch LogsまたはAmazon Kinesis Data Firehoseのいずれかを選択可能です。今回の設定ではCloudWatch Logsを使用しています。

図2: Amazon FSx 監査ログ設定

ファイルアクセス監査は、ファイルシステムが2021年6月8日以降に作成されたものであれば、Amazon FSxファイルシステムの作成時またはその後いつでも有効にすることができます。ファイルアクセス監査は、32MB/s以上のスループット容量を持つファイルシステムでのみサポートされます。監査が有効になると、設定が機能していることを検証するメッセージがイベントログの保存先に記録されます。

Amazon FSxの共有フォルダのルートに “secret “というフォルダを作成し、そこに “roadmap_do_not_share.doc “というファイルを格納します。このファイルのパーミッションを変更して、図3に示したセキュリティプリンシパルによるアクセスのみを許可します。これにより、fsxclientユーザーのアクセスが拒否されます。

図3: ファイルアクセスコントロールリスト

Amazon FSx for Windowsファイルサーバーの監査設定は、監査機能を有効にするだけです。ファイルやフォルダのイベントを取得するためには、図4のファイルエクスプローラーやPowerShellを使用して、ファイルやフォルダなどの個々のファイルシステムオブジェクトにNTFSシステムアクセスコントロールリスト（SACL）を使用して監査制御を設定する必要があります。フォルダの監査設定を行うには、そのフォルダを右クリックして「Properties」を選択し、「Security」タブに切り替えて「Advanced」をクリックします。

図4: フォルダプロパティ

これにより「Advanced Security Settings」が表示され、「Auditing」タブが表示され、図5に示すように個々の監査エントリを追加することができます。ここでは、Authenticated Usersグループによるフォルダ自体またはフォルダ内のオブジェクトへのアクセスに失敗したすべてのログを保存するように監査設定を行います。「Authenticated Users」グループは、サインイン手順を通じてシステムにアクセスするすべてのMicrosoft ADユーザーを含む特別なIDグループです。既存または新規に作成されたグループ、個々のユーザー、またはすべてのユーザーのEveryoneグループなど、他のすべてのセキュリティプリンシパルを使用することができます。

図5: ファイルエクスプローラーを使った監査ポリシーの設定

監査イベントをほぼリアルタイムで通知するアーキテクチャ

図6: 監査機能の論理図

 

監査イベントログのフィルタリング

インフラのセットアップが完了し、誰かがオブジェクトにアクセスしようとすると “Access Denied “メッセージが表示され、CloudWatch Logsのロググループにログイベントを受信しています。fsxclientユーザーとしてログインしたAdminサーバーからファイルアクセスリクエストを生成しています。この結果、図7に示すようなログイベントが発生します。

図7: CloudWatch Logsでの監査イベントの表示

すべてのイベントには、Amazon FSxファイルシステム上に生成されるWindowsイベントログレコードに見られる内容が正確に含まれています。図8は、秘密のロードマップファイル(“roadmap_do_not_share.doc”)にアクセスできないfsxclient Microsoft Active Directoryユーザーでアクセスしようとしたときのログイベントの詳細です。以下のログイベントでは、最も関連性の高い重要な情報を太字にしています。

  • オブジェクトへのアクセスが要求されたときに「イベントID 4656」が生成されます。
  • キーワード “0x8010000000000000” *¹は、アクセス試行の失敗(Audit Failure)を示します。
  • 「SubjectUserName」はファイルへのアクセスに使用されたユーザー名
  • 「ObjectName」はオブジェクトのパスと名前です。

<Event xmlns='http://schemas.microsoft.com/win/2004/08/events/event'><System><Provider Name='Microsoft-Windows-Security-Auditing' Guid='{54849625-5478-4994-A5BA-3E3B0328C30D}'/><EventID>4656</EventID><Version>1</Version><Level>0</Level><Task>12800</Task><Opcode>0</Opcode><Keywords>0x8010000000000000</Keywords><TimeCreated SystemTime='2021-05-24T22:44:34.112664300Z'/><EventRecordID>286071</EventRecordID><Correlation/><Execution ProcessID='4' ThreadID='924'/><Channel>Security</Channel><Computer>amznfsxywbathys.aws.corp</Computer><Security/></System><EventData><Data Name='SubjectUserSid'>S-1-5-21-3542593015-1953306266-3715292216-1144</Data><Data Name='SubjectUserName'>fsxclient</Data><Data Name='SubjectDomainName'>AWSCORP</Data><Data Name='SubjectLogonId'>0xd855722</Data><Data Name='ObjectServer'>Security</Data><Data Name='ObjectType'>File</Data><Data Name='ObjectName'>\Device\HarddiskVolume16\share\secret\roadmap_do_not_share.doc</Data><Data Name='HandleId'>0x0</Data><Data Name='TransactionId'>{00000000-0000-0000-0000-000000000000}</Data><Data Name='AccessList'>%%1541%%4423</Data><Data Name='AccessReason'>%%1541:   %%1805%%4423:  %%1811   D:(A;OICIID;0x1301bf;;;AU) </Data><Data Name='AccessMask'>0x100080</Data><Data Name='PrivilegeList'>-</Data><Data Name='RestrictedSidCount'>0</Data><Data Name='ProcessId'>0x4</Data><Data Name='ProcessName'></Data><Data Name='ResourceAttributes'>-</Data></EventData></Event>

図8: アクセス失敗のログイベント

*¹ – アクセス成功イベントのkeyword は”0x8020000000000000 ” となります。詳細はユーザーガイドを参照してください。

 

イベントIDとフォルダの名前を使って、CloudWatch Logsのログストリーム用のmetric filterを作成し、他のログエントリを破棄して、このフォルダやその中のオブジェクトへのアクセスに失敗した統計情報を提供しています。CloudWatch Logs Subscription Filtersは、イベントデータをAWS Lambdaのような追加ソースに渡す機能を提供し、イベントデータを解析するLambda関数をデプロイして、イベントメッセージで報告されたすべてのフィールドから有益な情報を得ることができます。

アラームが発生したときに役立つ詳細情報を提供するため、有益な情報を格納するためのmetric namespaceを作成します（図9参照）。名前空間として「folder/secret/4656」を使用し、フォルダ名とイベントIDを取得します。これにより、アラームに関連する電子メールを受信した際に、問題のフォルダと記録されたイベントIDを特定することができます。これは、1つのログイベントがパターンに一致すると、カウンターが1つ増加することを意味します。デフォルト値を0としたのは、マッチしないエントリーはカウンターに影響を与えないことを意味します。

図9: CloudWatchメトリックフィルタの作成

metric filterを定義した後、CloudWatchでメトリクスとして見ることができ、メトリクスを使ってCloudWatchアラームを設定することができます。ここでは、1分間のアクセス失敗数を表示するために、Sum関数で1分間と設定しています。

図10: CloudWatchの「アクセス拒否」カスタムメトリック

このソリューションでは、モニタリングを必要とするすべてのオブジェクトに、個別のmetric filterとmetric namespaceが必要です。例えば、ユーザーのホームフォルダを監視する場合、すべてのフォルダがメトリックを区別できるようにこれらを定義する必要があります。

アラームと通知の設定

さて、最後のステップは、不正アクセスの試行回数が増えたことを通知するアラーム自体の設定です。このプロセスは様々なユースケースに合わせて調整することができます。アクセスごとに通知を送信したり、全く通知を送信せず、CloudWatchコンソールでアラームの状態を監視するだけにすることもできます。図11に示すように、アラームのために1分間の長さで同じSum関数を使用します。アラームの閾値は、5回以上のアクセス試行失敗に設定します。閾値を超えた場合、電子メールによる通知がされます。また、「Missing data treatment」を「Treat missing data as good」に設定します。これはアラームが「データ不足」状態になるのを防ぐために必要です。この状態は、例えばユーザーの活動がなく、メトリックが統計を生成しない夜間に起こる可能性があります。静的な閾値の代わりに、CloudWatchの異常検出をメトリックに対して有効にすることができます。これは、統計および機械学習アルゴリズムを適用して、ユーザーの介入を最小限に抑えながら異常を報告しています。

図11: CloudWatchアラームの設定

通知は「In alarm」の状態に設定されており、Amazon SNSのトピックをトリガーにしてメールを送信します（図12参照）。

図12: CloudWatchアラームの設定

 

図13は、不正アクセスの試行に対して設定した閾値を超えた瞬間の、時間経過に伴うメトリック統計を示しています。

図13: CloudWatch アラームグラフ

 

結果

以下は、閾値を超えた時に受け取るメールのサンプルです。これは、この特定のアラームがどのフォルダとイベントIDに関連しているかを特定するのに役立つため、metric namespaceが活用されます。

You are receiving this email because your Amazon CloudWatch Alarm "AccessDenied" in the US East (Ohio) region has entered the ALARM state, because "Threshold Crossed: 1 out of the last 1 datapoints [6.0 (01/06/21 18:08:00)] was greater than the threshold (5.0) (minimum 1 datapoint for OK -> ALARM transition)." at "Tuesday 01 June, 2021 18:09:35 UTC".

View this alarm in the AWS Management Console:
https://us-east-2.console.aws.amazon.com/cloudwatch/deeplink.js?region=us-east-2#alarmsV2:alarm/AccessDenied

Alarm Details:
- Name:                       AccessDenied
- Description:               
- State Change:               OK -> ALARM
- Reason for State Change:    Threshold Crossed: 1 out of the last 1 datapoints [6.0 (01/06/21 18:08:00)] was greater than the threshold (5.0) (minimum 1 datapoint for OK -> ALARM transition).
- Timestamp:                  Tuesday 01 June, 2021 18:09:35 UTC
- AWS Account:                231573846347
- Alarm Arn:                  arn:aws:cloudwatch:us-east-2:231573846347:alarm:AccessDenied

Threshold:
- The alarm is in the ALARM state when the metric is GreaterThanThreshold 5.0 for 60 seconds.

Monitored Metric:
- MetricNamespace:                     folder/secret/4656
- MetricName:                          AccessDenied
- Dimensions:                         
- Period:                              60 seconds
- Statistic:                           Sum
- Unit:                                not specified
- TreatMissingData:                    notBreaching

State Change Actions:
- OK:
- ALARM: [arn:aws:sns:us-east-2:231573846347:Inform_about_access_denied]
- INSUFFICIENT_DATA:
--

皆様のケースがこのテストと完全に一致しないかもしれませんが、不正アクセスの試みが記録されてからメール通知を受信するまでの時系列を以下に示します。

  • イベントのタイムスタンプは18:07:09～18:07:46（イベント数が設定した閾値を超える）
  • 18:09:35にCloudWatchのアラームが発生（状態がOKからALARMに変更）。
  • 受信箱にメールが届く 18:10:44

このタイムラインは、CloudWatchメトリック、CloudWatchアラーム、SNSトピック、メールシステムなど、お客様の構成によって異なります。

テスト後の削除

コストがかからないように、テストが終わったらデプロイメントを削除することを忘れないでください。コンソールで作成したリソースを削除するか、AWS CloudFormationを利用してInfrastructure as Codeアプローチを採用している場合は、関連するスタックをすべて削除します。

まとめ

Amazon FSx for Windows ファイルサーバーは、ファイル、フォルダ、およびファイル共有へのエンドユーザーのアクセスを監査することをサポートし、セキュリティとコンプライアンスの対応をさらに進めるために、ログの照会、処理、保存、およびアーカイブとトリガーアクションを可能にします。このブログでは、Amazon FSxでファイルアクセス監査を設定する方法を説明しました。監査イベントを蓄積するためにCloudWatch Logsを使用し、不審なユーザーアクセスに似たパターンに従ってイベントをフィルタリングし、CloudWatchメトリクスとして不審なアクセスの発生をカウントしました。CloudWatchメトリクスを使って、メトリクスの閾値を超えたときにCloudWatchアラームを作動させ、電子メールで通知する方法を紹介しました。この方法は、様々なユースケースに合わせてさらにカスタマイズすることができます。新しいファイルアクセス監査機能は、Amazon FSxファイルシステムのアクセスパターンを可視化し、お客様のセキュリティをさらに強化することを可能にします。

Amazon FSxのファイルアクセス監査は、Amazon FSxが利用可能なすべてのAWSリージョンにおいて、追加費用なしで利用できます。その機能については、Amazon FSxのドキュメントで詳細をご覧ください。