Amazon Web Services ブログ

AWS Transfer for SFTP でビッグデータと分析のエンゲージメントをサポート

Leap Beyond は、ビッグデータに特化した、多国籍の専門コンサルティング会社です。当社の目標は、中規模から大規模までのエンタープライズが、データを使用してビジネスや利益に大きな影響を与える変化をもたらすことができるように支援することです。私は業務執行社員という役職柄、当社のエンジニアがクライアントとどのように連携して安全かつ効率的にデータを移動、変換しているかということに特別な責任と関心を持っています。

Leap Beyond のようなデータを主に扱うコンサルティング会社にとってよくあるシナリオは、クライアントがオンプレミスまたはクラウド環境から AWS クラウドへの機密データの移行を検討中であるというものです。クライアントがデータを AWS にコピーしたい理由はいくつもあります。こうしたクライアントがオンサイトでこの作業に取り組むのは困難な場合があります。必要なツールや処理能力が自社の環境内で利用できなかったり、自社のデータストアへのアクセス権が環境外のサービスにはなかったりするためです。このようなクライアントは多くの場合、未加工の情報ではなく、加工済みデータを提供したいと考えているでしょう。機密データを貴社 (コンサルティング会社) の管理下にある Amazon Simple Storage Service (Amazon S3) バケットにダンプできるようにすることを最も単純な目標として掲げるこうしたシナリオはすべて実現可能です。貴社は、処理、分析、および ML に多数のサービスを利用しながら、必要なときにコンピューティングリソースをスピンアップできます。AWS Transfer for SFTP を使用することで、顧客は貴社の S3 バケットにデータを安全にアップロードするための追加オプションを利用できるようになりました。本稿ではここから、このオプションを活用する方法について説明していきます。

Amazon S3 を使用した AWS Transfer for SFTP

セキュリティ保護可能なデータストアである Amazon S3 は非常に堅牢です。保管中のストレージのコストやデータの送受信にかかるコストは低く、ゼロに近づいています。保管時にサーバー側で透過的な暗号化を提供する便利な方法や、クライアント側の暗号化を行う極めて便利な方法があります。アクセス制御や監査をきめ細かく行うことができ、誤操作でもしない限り、アクセスを厳しく制限できます。不注意にバケットをインターネットに公開したままにしておくという古き悪しき時代は、遠い過去へと過ぎ去りました。今では、パブリックアクセス用に S3 バケットを公開するには意図的な操作が必要です。Amazon S3 ブロックパブリックアクセスの使用についての詳細をご確認ください。または、短い AWS ブログ記事 Learn how to use two important Amazon S3 security-features: Block Public Access and S3 Object Lock をご覧ください。

クライアントは Amazon S3 の使用にあたって、 AWS コマンドラインインターフェイス (CLI) ツールもしくはサードパーティーの S3 クライアントソフトウェアをインストールするか、または AWS マネジメントコンソールを使用してアカウントにログインしウェブブラウザ経由でバケットにアクセスする必要があります。どちらの場合も、クライアントに貴社アカウントへのアクセス認証情報を提供し、その認証情報の交換を安全に管理する必要があります。AWS Transfer for SFTP では、認証に SSH キーを使用できるために安全なオプションを増やせるほか、SFTP の堅牢で実績のあるセキュリティを利用することができます。

SFTP と S3 の組み合わせによって優れたセキュリティが得られることに加えて、Leap Beyond とクライアントには 2 つの大きなメリットがあります。1 つ目は、AWS コマンドラインインターフェイス (CLI) をインストールしてファイルを送信する方法を習得できない (もしくはそれに抵抗がある) クライアントでも、使い慣れたツールを使用してデータを送信できるようになったことです。2 つ目は、SSH キーペアの使用によってクライアントが転送中のデータのセキュリティを大いに制御できることです。パスワードやその他の認証情報ではなくキーペアを使用することで、定期的に取り消したり更新したりできるファイル転送専用の認証情報を簡単に取得できます。データは暗号化されたトンネルを使用して安全に転送されるため、クライアントと当社の間でキーマテリアルを安全に交換できます。

AWS Transfer for SFTP サーバーを作成する

ユーザーガイドには使用開始のステップが記載されていますが、3 つのステップがあることが明確に書かれているわけではありません。これらは、CloudFormation または Terraform (組織で使用するものによります) を使用して論理的に自動化できます。

バケットを作成する

最初のステップとして、すべてのパブリックアクセスをオフにしてバケットを作成します。サーバー側の保管時の暗号化 (Amazon S3 のサーバー側の暗号化または Key Management Service のいずれかを使用) を有効にし、必要な S3 アクセスログ記録バージョニング、およびライフサイクル管理を活用するのが理想です。これは標準の S3 バケットと何ら変わりないので、標準のバケットポリシーと Infrastructure as Code ツールを簡単に適合させることができます。余談ですが、SFTP のターゲットとして使用されるバケットは、データを保持する場所にはしないことをお勧めします。ファイルを入手する時に “ドロップボックス” バケットから “作業中” バケットに移動させるデータパイプラインを設定するのは簡単です。こうしておけばデータが公開されるリスクに対する保証が追加されます。このバケットは内部アクセスのみに使用されるバケットとは異なり、DMZ に存在するものであると考えてください。

IAM ロールとポリシーを作成する

次に、SFTP サービスがバケットに対して読み書きできるようにする IAM ロールとポリシーが必要です。ユーザーガイドには、この要件とプロセスの明確なチュートリアルが掲載されています。SFTP サービスとバケットのペアのインスタンスごとに、異なるロールとポリシーを用意することをお勧めします。ロールとポリシーは基本的に無料で、異なるものを用意した方が監査がはるかに簡単になります。また、先日の AWS ブログ記事で説明されているように、2019 年 9 月にリリースされた新しい論理ディレクトリ機能を使用してユーザーを “chroot” することを強くお勧めします。そうすることで、貴社は安全性を確保でき、ユーザーにとっては閲覧がシンプルになります。

SFTP サーバーを作成する

最後から 2 番目のステップとして、SFTP サーバーを作成します。繰り返しになりますが、ユーザーガイドはここでも役立ちます。作成ウィザードも分かりやすく設計されています。エンドポイントは、パブリック (クライアントに公開したいもの) にするか、VPC に結び付けることができます (オンプレミスネットワークへのプライベート接続を持つ VPC がある場合に役立つでしょう)。ここでは “サービス管理” アイデンティティを使用します。SSH キーペアを使用しており、識別や分類をする目的でサーバーとユーザーにタグ付けしているからです。必要に応じて、サーバーのホストキーを割り当てることができます。クライアントの環境に既に登録されているものを使用する方が良いでしょう。これにより、同じクライアントとのエンゲージメント間で異なるサーバーを使用した場合に、見るからに忌まわしい “中間者攻撃” メッセージがクライアント側に送られるのを防ぎます。

ユーザーをサービスに追加する

最後のステップは、ユーザーをサービスに追加することです。この時点で、SFTP エンドポイントと作成済みのバケットの間に関連付けが形成されます。このサービスのセキュリティモデルにおける巧妙な点は、SFTP サービス自体がバケットを認識しないことです。その代わりに、以前に作成済みでユーザー作成中に指定する IAM ロールが、特定のバケットに対するユーザーのアクセスを管理します。別の副次的な効用として、ユーザーごとに異なるバケットを使用できる点があります。さらに、ユーザー設定によりバケット内のホームディレクトリを指定できます。これにより、ユーザーごとに異なるファイルシステムの仮想ルートが実現できます。この AWS ブログ記事で説明されているように、セキュリティを強化するために、S3 バケットの特定の場所にユーザーを “chroot” することができます。

この時点で、クライアントは特定の間隔で、またはアドホックで、データの送信を開始できるようになります。アップロード後の処理は、抽出、変換、分析のために S3 イベントを使用してデータパイプラインで自動化できます。

最後の考察

AWS のすべてのサービスと同様、費用対効果を最大限に高めるには、関連するコストを認識することが重要です。AWS Transfer for SFTP を使用すれば、ストレージとデータ転送のコストが抑えられます。サービスにおけるプロビジョニングの基本コストは 0.30 USD/時間で、換算すると約 216 USD/月になります。驚くほど高速なアップロードと事実上無制限のストレージと共に、確かなセキュリティ、信頼性、可用性を手に入れることができます。しかも管理コストと保守コストはごくわずかです。クライアントに常時稼働サービスを提供している場合、これは確かに費用対効果が高い手法です。

ただし、サービスのコストを合理的に評価する必要があります。開発とテストのためだけに使用している場合、またはクライアントがデータのアップロードを定期的に行わない場合は、使用中にサービスがプロビジョンされた状態を保つことのみを検討してもよいでしょう。バケット、ロール、ポリシーを分解する必要がない場合、2 つのオプションのコストのみを評価するべきです。つまり、必要に応じて AWS Transfer for SFTP サーバーを分解して再構築する方が、実行したままにするよりも、コストがかかってしまうのです。実行したままにしておいても、そのコストは 1 日につきたったコーヒー 2 杯分なのですから!