Amazon S3 セキュリティベストプラクティスの実践（権限管理のポリシー) – 前編

はじめに

AWS では、サービス毎にセキュリティのベストプラクティスを公式ドキュメントとして提供しています。本記事では AWS を利用したシステムのセキュリティの検討や実装に関わる皆様を対象に、AWS の代表的なストレージサービスである Amazon Simple Storage Service (S3) を題材にとりあげて、公式ドキュメントで紹介しているベストプラクティスの実装方法をできるだけ具体的に解説したいと思います。

IT セキュリティにおいては、一つの脆弱性や悪意がセキュリティ事故に直結しないようにシステムを多層的に保護する事が重要です。AWS においても、サービスが提供する機能を適所でご利用いただければ多層化されたセキュリティ保護策を、クラウドならではのスピード感であなたの IT システムに配備することができると考えています。ですが、今までネットワーク境界防御に重きをおいてセキュリティ対策されていたような組織にとっては、AWS マネージドサービスを権限管理や暗号化などの方法で保護するというベストプラクティスがちょっと取っ付きづらく見えることもあるようです。私たちプロフェッショナルサービスのコンサルタントは日頃、お客様先においてビジネスの成功につながる AWS 利用の how をガイドしています。コンサルタントが様々なクラウド利用の現場で得たノウハウを元に、ベストプラクティスを噛み砕いてご紹介することで、みなさまのご理解の一助となればと考えています。

今回の内容は１つの記事でまとめてご紹介したかったのですが、長くなってしまったので前後編に分けて投稿する予定です。前編である今回は権限管理に関するポリシーの使い分けの考え方を、後編ではよくあるモデルケースを想定したポリシーの構成例をご紹介します。

（2020/6/24に後編を公開しました。）

Amazon S3 のセキュリティベストプラクティス

Amazon S3 のセキュリティのベストプラクティスは、公式ドキュメントの開発者ガイドにて公開されています。予防的対策として、権限管理、暗号化といった機密性を保護する機能と、バージョニングや改ざん抑止などの完全性を保護する機能が記載されていますが、本記事では、権限管理についてご紹介します。 (なお、Amazon S3 以外のサービスでもセキュリティのベストプラクティスが開発者ガイドに順次追加されています。この機会にぜひご確認ください。)

Amazon S3セキュリティベストプラクティスで紹介している予防的対策
（★の部分を本ポストで考察します。）

• Amazon S3 バケットに正しいポリシーが使用され、それらのバケットが公開されていないことを確認する（パブリックアクセスブロック）★
• 最小限の特権アクセスを実装する★
• Amazon S3 アクセスを必要とするアプリケーションと AWS サービスには IAM ロールを使用する
• MFA (多要素認証) Delete を有効にする
• 保管時のデータの暗号化を検討する
• 転送中のデータの暗号化を強制する
• Amazon S3 オブジェクトロックを検討する
• バージョニングを有効にする
• Amazon S3 クロスリージョンレプリケーションを検討する
• Amazon S3 アクセス用の VPC エンドポイントを検討する

４つのポリシータイプをそれぞれ異なる目的のために使い分ける

権限管理は予防的なセキュリティ対策の土台となる重要要素です。オンプレでも、OS やアプライアンスの特権アカウントは適切な管理者しか利用できないように特権 ID 管理を行っているかと思いますが、AWS ではインフラストラクチャに関する多くのオペレーションをネットワーク経由のサービス (API) として実行できる特性から、権限で統制する機能の範囲が広くなっています。例えば、仮想サーバの起動停止などから、ファイヤウォールの開け閉め、さらにはデータのバックアップなどの様々な操作を権限管理システムで統制する形になります。AWS では、この権限管理を主に AWS Identity and Access Management (IAM) サービスが担っています。

IAM では、AWSの各種サービスや操作の権限を管理者や利用者に割り当てることができます。多様なユースケースに対応できるように、構造化された記述で権限を割り当てることができ、このような記述をポリシーと呼んでいます。ポリシーは関連付けられるサービスや機能によって様々なタイプが存在し、Amazon S3のベストプラクティスでも適所で使い分けることを推奨しています。

ご紹介する４つのポリシータイプと用途

注釈1：リソースベースのポリシーは様々な AWS リソースで利用可能です。アタッチされるリソースによって別名で呼ばれることもあり、KMS の暗号鍵にアタッチするキーポリシーや、S3 バケットにアタッチするバケットポリシーなどがあります。各サービスの対応状況は、公式ユーザーガイドで調べることができます。

アイデンティティベースのポリシーで権限管理の土台を作る

アイデンティティベースのポリシーは、ユーザやロール (AWSではこれらをまとめてプリンシパルと呼んでいます) に権限を割り当てるために使用します。例えば、S3 管理者には Amazon S3 の設定管理も含めて権限 (Action s3:*) を割り当て、データ利用者には Amazon S3 のデータアクセスの権限 (Action s3:getObject, s3:putObject) だけを割り当てる、というような構成です。このとき、利用対象のリソースや条件を指定することもできます。例えば、S3 管理者はすべての S3 バケットの操作権限（Resource s3:::*)を割り当て、データ利用者には特定のバケットの権限 (Resource s3:::blue-app-data-bucket) だけを割り当てるということができます。

これらの要素を組み合わせることで、このアイデンティティベースのポリシーだけで、Amazon S3の権限管理を完結することもできます。では、なぜベストプラクティスではアイデンティティベース以外のポリシーの利用も推奨しているのでしょうか？

リソースベースのポリシーで利用条件を定義する

AWS ではリソースへの各種アクセスや操作を、リソースにセットする権限管理のポリシーで制御することもできます。このリソースにセットするポリシーのことをリソースベースのポリシーと呼びます。前述の通りアイデンティティベースのポリシーでもリソースを指定して権限を制御できるのに、なぜリソースベースのポリシーが存在するのでしょうか？ 実際の運用を考えてみるとユースケースが見えてきます。

例として、新しいアプリケーションを既存の AWS システムに追加するケースを考えてみます。データレポジトリやログの保管領域として S3 バケットをいくつか追加するとします。アイデンティティベースのポリシーでリソースを制限していた場合、新たに S3 バケットの追加が発生する都度、既存のポリシーに新しい S3 バケットをいちいち追記していくことになります。これでは、既存アプリケーションへの影響確認が必要になってしまう可能性があります。一方、リソースベースのポリシーを使用すれば、新たに追加した S3 バケットにセットするリソースベースのポリシー（バケットポリシーと呼びます）で、許可する管理者や利用者を指定できますから、既設ポリシーへの影響を排除することができます。逆に S3 バケットを削除する場合も同様です。 (注釈2)

また、リソースベースのポリシーの重要な機能として、利用条件の制御があります。例えば、特定のVPCのみからしかデータアクセスさせたくない S3 バケットがあるとします。バケットポリシーに VPC 条件を記載すればこれを実現することが簡単にできます。アイデンティティベースのポリシーだけでこれを実現しようとすると、対象となるすべてのプリンシパルのポリシーにVPC条件を追記する必要があります。

アイデンティティベースのポリシーでの制御例

リソースベースのポリシーでの制御例

注釈2　よりスケールの求められるユースケースでは、リソースの属性情報を用いてアクセスを制御する Attribute-based access control (ABAC) という手段もあります。2020年5月1日現在、S3 ではオブジェクトリソースに対してのみタグベースの認証をサポートしています。

エンドポイントのポリシーで管理外リソースへのアクセスを遮断する

VPC エンドポイントに紐付けるポリシーもベストプラクティスにて検討が推奨されています。VPC エンドポイントは、お客様専用の仮想 NW (VPC) に設置する特定 AWS サービス用のアクセス経路です。インターネットへの接続口を設けずに、VPC の外にある Amazon S3 のようなマネージドサービスに対してアクセスできるため、AWS インフラストラクチャを閉域 NW で利用したいユースケースで利用されます。

Amazon S3 はお客様の VPC の外の NW に存在するサービスなので、通常は VPC に Internet Gateway をアタッチしないと VPC 内の仮想サーバやアプリケーションから利用できませんが、VPC エンドポイントをその NW サブネットにアタッチすると、インターネットへの接続は抑制しつつ、Amazon S3 のみへアクセスできるようになります。たとえば、アプリケーションサーバ等を配置するプライベートなネットワークから、C&C サーバ等への不正な通信を NW 的に遮断するようなユースケースで用いられます。

Internet Gateway による広範なアクセス経路	VPC エンドポイントによるS3に限定したアクセス経路

ただ、この VPC エンドポイントは、初期状態では AWS アカウントの垣根を超えてそのリージョンのすべての S3 バケットへのアクセス経路を提供するので、自アカウント以外の S3 バケットへのアクセスを制限したいケースでは注意が必要です（注釈3）。自アカウントの S3 バケットにしかアクセスできないようにする制御は、前述のようにアイデンティティベースのポリシーでも実装することができますが、非常に手間でもあります。それをより簡便に実装することができるのが VPC エンドポイントポリシーです。

VPC エンドポイントポリシーは、基本的には IAM ポリシーと同様の構文ルールになっており、リソース句を指定してアクセスできる S3 バケットを制御することができます。また、リソースベースのポリシーと同じようにプリンシパル句を使って利用者を指定することもできます。以下の図のように、アクセス可能なバケット名をホワイトリスティング形式で使用したり、暗号鍵の条件を使用することで、管理外領域への情報フローを制限することができます。

エンドポイントポリシーを使用した特定 S3 バケットに限定したアクセス経路

注釈3:　通常、S3バケットは所有者のアカウントしかアクセスできないようにACLが設定されていますが、攻撃者などがどのAWSアカウントからでもアクセスできるように意図的に公開したバケットに対しては、自分のアイデンティティポリシーで対象リソースの制限がない S3 権限を割り当ててしまっているとアクセスできてしまいます。

サービスコントロールポリシーで不要な機能を無効化する

AWS Organizations というAWS アカウントを統合管理するサービスがあります。複数のアカウントのセキュリティや課金をマスターアカウントから一元的に管理するサービスで、多数のアカウントを駆使して AWS を利用いただくユースケースでは便利なサービスです。この AWS Organizations で、配下のアカウントに統一的なセキュリティ基準を適用するために使用するのがサービスコントロールポリシー (SCP) です。SCP を使用して、アカウント内で利用可能な権限を制限することができます。例えば Amazon S3 には、静的 Web サーバのようにコンテンツを提供できる Web サイトホスティング機能がありますが、データを外部公開する必要のないアカウントにおいてはこの機能が不要なケースもあります。そのような時に SCP で Web サイトホスティングの権限を無効化できます。SCP で禁止されると、たとえそのアカウントの最高権限 (AWS アカウントのルートユーザー) であってもその権限を利用できなくなります。

ACL はユースケースを慎重に見極める

Amazon S3 は4つのポリシータイプを使用してアクセスを統制できることを前の章でご紹介しましたが、他にも「Amazon S3 アクセスコントロールリスト (ACL)」という重要な機能があります。ACL を使用すると、Amazon S3 を他のアカウントやパブリックに簡単に公開することができます。ACL はバケット単位に設定できるだけでなく、データ (Amazon S3 ではオブジェクトと呼びます) 単位に設定することができるため、一つのバケット上のデータを複数の異なるアカウントにそれぞれ必要な単位で公開することができます。

一方、センシティブなデータを取り扱うアカウントなどにおいては、ACL 機能の特徴を見極めて慎重な運用が求められるケースもあります。コンソールや API によるシンプルな操作でデータを公開することができるため、この ACL 関連権限は本当に必要なプリンシパルにしか割り当てないような運用が求められることもあります。多くのユースケースにおいてバケットポリシーによるアクセス統制で十分です。ACL でないと対応できない一部のケース以外は、できるだけバケットポリシーを使用します。

パブリックアクセスブロックを使用する

前述の4つのポリシーと ACL 関連権限が適切に運用されていれば、Amazon S3 上のデータが管理者の意図を超えて公開されることを予防できます。それでもなお、意図しないパブリック化をいかに抑止するかというのは Amazon S3 を使用する際の主要な検討事項です。設定ミスや管理の不行届が原因の漏洩リスクに対する多層防御が多くのユースケースで求められています。Amazon S3 においても、ポリシーや ACL による防御だけでない多層的な防御手段が複数提供されています。その一つが S3 セキュリティベストプラクティスで紹介されている、パブリックアクセスブロック機能です。

S3 パブリックアクセスブロックを使用すると、アカウント管理者とバケット所有者は、リソースの作成方法に関係なく、Amazon S3 リソースへのパブリックアクセスを制限するための一元管理を簡単に設定できます。
(開発者ガイド)

パブリックアクセスブロックは、前述のリソースベースのポリシー (バケットポリシー) や ACL をオーバーライドして、パブリック公開を防ぐ機能です。例えば管理者が誤ってバケットポリシーや ACL でパブリックにしてしまったとしても、パブリックアクセスブロックを有効にすれば、既存の公開設定は無効になり、新たに設定することもできなくなります。パブリックアクセスブロックはアカウント単位にも設定できるため、そのアカウントのいかなるバケットやオブジェクトもパブリックにならないように統制できますし、これを組織単位に強制 (AWS Orgnizations の サービスコントロールポリシー機能を利用) することもできます。

まとめ

本記事では、Amazon S3 を題材に AWS のセキュリティベストプラクティスの中でも権限管理の実装について解説しました。ポリシーには、アイデンティティベース、リソースベース、VPC エンドポイントポリシー、サービスコントロールポリシー の4つの主要な形態があり、それぞれ異なる目的で使い分けができることをご紹介しました。また、これらのポリシーを補完するパブリックアクセスブロック機能もご紹介しました。次回は、これらのポリシーを実際のユースケースに当てはめてご紹介します。またお会いしましょう。

このブログの著者
中村 賢介 (Nakamura, Kensuke)
プロフェッショナルサービス本部　セキュリティコンサルタント