Amazon Web Services ブログ
アプリケーションのログファイルを第三者と安全に共有する方法
アプリケーションに障害が発生し、トラブルシューティングのためにインスタンスレベルのログデータを外部の組織に提供しなければならない場合、どうすればよいでしょうか。本番環境のリソースに対しては、人による直接的なアクセスは可能な限り制限することが推奨されるため、一定の期間のみ、一時的なアクセス許可を提供することがよくあります。一方で規制の厳しい業界では、本番環境へのアクセスの承認プロセスが難しく、許可されないことがあります。このような場合、ユーザーが Amazon Elastic Compute Cloud (Amazon EC2) インスタンスに接続して、それらのログデータを取得することはできません。
Amazon CloudWatch エージェントは、ログファイル収集機能によって Amazon CloudWatch Logs へのファイルの取り込みを自動化することで、この状況を改善することができます。しかし、このソリューションは、ログデータを第三者（例えば、パートナーや ISV サポートチーム）と共有する場合など、あらゆるシナリオに適しているわけではありません。お客様は、AWS アカウントへの特定のアクセス許可を使用して、これらの第三者のアクセスを許可する必要がありますが、これは多くのセキュリティ・オペレーション (SecOps) チームにとって、現実的ではない可能性があります。さらに、多くの外部組織は、ログファイルを従来の ZIP アーカイブで受け取ることを好みます。
お客様は、アプリケーションログを継続的に収集し、安全でコストが最適化されたストレージに保存するプロセスを必要としています。これらの収集されたログファイルは、SecOps チームによる管理と監査が容易な方法で、外部の関係者が安全に利用できるようにする必要があります。
本ブログでは、社内システムで実行されているアプリケーションログを一元管理し、効率的に保存し、安全にアクセスするためのマネージドソリューションを提供します。AWS マネージドサービスを使用すると、カスタムコードや手間のかかる作業を必要とせずに、アプリケーションログの共有パイプラインを簡単に実装できます。本ブログで紹介するアーキテクチャは以下の通りです。
- Amazon FSx for Windows File Server を使用した、ログファイルの一元管理
- AWS DataSync を使用した、ログファイルの Amazon S3 バケットへの同期
- AWS Transfer Family を使用した、外部関係者へのセキュアなアクセスの提供
エンドツーエンドのアーキテクチャ
図 1: システムアーキテクチャ
図 1 は、中央の共有ログストアから外部組織へのアクセスまでのソリューションアーキテクチャを示しています。設定の手順は以下の通りです。
- Amazon FSx が提供する SMB (Server Message Block) 共有をマウントするように、Amazon EC2 インスタンスを構成し、その場所にログファイルを保存するようにアプリケーションを構成します。
- DataSync を使用して、Amazon FSx に保存されているログファイルを Amazon S3 バケットにレプリケートします。
- AWS Transfer Family を設定して、SFTP プロトコルで Amazon S3 バケット内の適切なログファイルへの指定ユーザーアクセスを提供します。
AWS Cloud Development Kit (CDK) を使用して、このパターンのテストを目的とした環境をデプロイするためのテンプレートを作成しました。このテンプレートは、すべてのリソースを起動するのに約 2 時間かかります。Amazon FSx や、Windows および Linux の Amazon EC2 インスタンスを起動して Amazon S3 にファイルを同期し、SFTP を使用して AWS Transfer Family 経由で利用できるようにします。カスタマイズの詳細については、リポジトリ のホームページを参照してください。
各コンポーネントについて簡単に説明し、ソリューションを個別に構築する方法を詳しく説明します。ユースケースに合わせてカスタマイズすることができるように、関連ドキュメントへのリンクも記載しています。
Step 1: アプリケーションのログを Amazon FSx for Windows File Server に格納
図 2: Step 1 のスコープ – 中央ログストアに関するサービス
Amazon FSx は、広く使われている 4 つのファイルシステムをサポートしています。NetApp ONTAP、OpenZFS、Windows File Server、Lustre です。ソリューションのアーキテクチャは、Amazon FSx for Windows File Server のファイルシステムをプロビジョニングするところから始まります。以下の例では、Amazon FSx ファイルシステムは、高可用性のためのマルチ Availability Zone (AZ) 構成やパフォーマンス向上のための SSD ストレージなど、本番環境で推奨される設定を使用しています。
図 3: Amazon FSx ファイルシステム作成コンソールのオプション
Amazon FSx for Windows File Server は、業界標準の SMB プロトコルでアクセス可能な、フルマネージド、高信頼性、スケーラブルなファイルストレージサービスです。Windows Server 上に構築されており、Microsoft Active Directory との統合やユーザークォータなどの管理機能を提供します。Amazon FSx for Windows File Server は、設定が非常に簡単な中央ログストアとして機能します。お客様は、AWS Systems Manager Run Command またはグループポリシーを使用して、ログディレクトリへのファイル共有のマウントを自動化できます。ファイル共有をアタッチした後、この場所にログファイルを書き込むようにアプリケーションを構成します。
必要に応じて、これらの手順を Linux ベースのワークロードに適用することもできます。そのためには、Amazon FSx for Windows File Server を、フルマネージドの NFS ファイルシステムである Amazon Elastic File System に置き換える必要があります。ハイブリッド環境では、Amazon FSx for NetApp ONTAP の使用を検討してください。NetApp ONTAP は、Windows SMB と Linux NFS クライアントに対するマルチプロトコルでのファイル共有をサポートしています。
Linux ベースのワークロードのユースケースについては、以下の情報を参照してください。
- Amazon EFS ファイルシステムを作成する
- EC2 インスタンス起動ウィザードから Amazon EFS ファイルシステムを自動でマウントするには
- Amazon FSx for NetApp ONTAP の開始方法
Step 2: アプリケーションログファイルを Amazon S3 バケットへレプリケート
図 4: Step 2 のスコープ – ログファイルのレプリケーションに関するサービス
Amazon FSx を使用してログファイルを一元化した後、Amazon FSx ファイル共有を Amazon S3 バケットにレプリケートするように AWS DataSync を構成します。始めに、AWS DataSync が使用する 2 つのロケーションを作成します。1 つ目のロケーションは、先ほどプロビジョニングした Amazon FSx ファイル共有です。2 つ目のロケーションは、集約されたすべてのログファイルを格納する Amazon S3 バケットです。これが完了したら、スケジューリング、アーカイブ、スロットリング制御など、すべてのレプリケーション設定を含むタスクを作成します。詳細については、Amazon FSx for Windows File Server から Amazon S3 への DataSync レプリケーションの設定に関する投稿を参照してください。
図 5: Amazon FSx for Windows File Server ファイルシステム作成コンソールのオプション
AWS DataSync は、各 Amazon EC2 Windows インスタンスへの直接接続をサポートしています。しかし、このアプローチは規模が大きくなると運用上複雑なモデルになります。AWS DataSync は、スケジューリング、アーカイブ、スロットリングの制御に加えて、エンドツーエンドの暗号化を使用してデータを安全に転送します。このサービスはサーバーレスであり、お客様はコピーされたデータに対してのみ料金を支払います。
タスクが正常に実行されると、アプリケーションログが Amazon S3 バケットにレプリケートされます。Amazon S3 ライフサイクルポリシーを使用して保持期限を設定したり、ストレージクラスを変更したり、古いファイルを自動的に削除したりできます。
Step 3: AWS Transfer Family を使用した、アプリケーションログファイルへのセキュアで監査可能なアクセスの設定
図 6: Step 3 のスコープ – 外部組織からのアクセスに関するサービス
最後に、AWS Transfer Family を使って、Amazon S3 バケットを Secure Shell (SSH) File Transfer Protocol で安全に公開します。このサービスはいくつかのプロトコルをサポートしています。SFTP 対応サーバーの作成方法については、こちらの AWS ドキュメントを参照してください。
図 7: AWS Transfer Family コンソールのオプション
AWS Transfer Family はサーバーレスであり、お客様はアクセス制御と AWS CloudTrail を通じた使用状況の監査を行うことができます。AWS CloudTrail はクラウドリソースを監視し、AWS マネジメントコンソール、AWS SDK、コマンドラインツール、および上位の AWS サービスを使用して行われた API コールを含む、アカウント内のあらゆる AWS API コールの履歴を作成します。また、発信元 IP アドレス、発信者の AWS IAM ID、関連プロパティなどのメタデータも収集します。
Step 4: パイプラインの健全性の監視
Amazon EC2 フリートのアプリケーションログを Amazon S3 に自動的にレプリケートし、外部パートナーが利用できるようにするエンドツーエンドのソリューションが完成しました。このパイプラインはマネージドサービスによって構築されており、メンテナンスはほとんど必要ありません。ログパイプラインの運用状態を確認するために、Amazon CloudWatch を使用します。このソリューションのパフォーマンスを可視化することで、AWS リソースの使用状況を検知、対応、最適化することができます。
基本的なソリューションとして、サービスの組み込みの Amazon CloudWatch メトリクスを Amazon CloudWatch アラームに統合することもできます。アラームのトリガー後は、電子メールの送信、カスタム AWS Lambda 関数の呼び出し、メトリクスストリームを使用した SaaS ソリューションへの通知など、さまざまなアクションを通じて自動的に応答できます。この柔軟性により、既存のプロセスと推奨のツールを迅速かつ簡単に統合できます。
Step 5: クリーンアップ
作成したリソースに対する課金を停止するために、まず Step 2 の Amazon S3 バケットを空にする必要があります。次に、CloudFormation スタックを削除して、管理対象のリソースを削除します。全てのリソースを手動で設定した場合は、AWS Transfer Family サーバー、DataSync リソース（エージェント、タスク、ロケーション）、Amazon FSx for Windows File Server ファイルシステム、そしてその他の一時的な Amazon EC2 インスタンスを削除します。
費用の詳細については Amazon FSx for Windows Filer Server、AWS DataSync、AWS Transfer Family、Amazon CloudWatch、Amazon S3 の料金ページをご参照ください。
まとめ
アプリケーションログファイルを継続的に収集し、外部の関係者と安全に共有することは困難な場合があります。セキュリティポリシーでコンピューティングリソースへの直接アクセスが許可されていない場合、この問題はさらに複雑になります。この投稿では、外部パートナーがアプリケーションログファイルへ安全にアクセスできるようにする方法を説明しました。AWS のマネージドサービスを利用することで、コンピューティングインスタンスへの直接アクセスやカスタムコードが必要なくなります。また、特定のユースケースに合わせて、個々のコンポーネントを自由に組み合わせることもできます。AWS CDK のサンプルコードを試して、安全かつ再現性のある方法で特定のファイルレベルのアクセスを提供することがいかに簡単かを確認してください。
AWS Transfer Family やこのブログで紹介した他のリソースについてもっと知りたい方は、以下の情報を参照してください。
本記事は How to securely share application log files with third parties（2022 年 1 月 31 日公開）を翻訳したものです。翻訳は、ソリューションアーキテクトの宮城が担当しました。
著者紹介