一時的認証情報を使用してフェデレーティッドアイデンティティで、Amazon Athena に接続する
一時的認証情報を使用してフェデレーティッドアイデンティティで、Amazon Athena に接続する:
多くの組織では、集中化されたユーザー管理、特に Microsoft Active Directory または LDAP が標準となっています。 AWS リソースへのアクセスも例外ではありません。 Amazon Athena は、データレイク内のデータの迅速で費用効果の高いクエリで一般的である、Amazon S3 のデータ用のサーバーレスクエリエンジンです。 ユーザーまたはアプリケーションが Athena にアクセスできるようにするために、組織は AWS アクセスキーと適切なポリシーが適用されているアクセス秘密鍵を使用する必要があります。一貫性のある認証モデルを維持するために、組織はフェデレーテッドユーザーを使用して Athena の認証と承認を有効にする必要があります。
このブログ記事では、AWS Security Token Service (AWS STS) を使用してフェデレーテッドユーザーによるアクセスを有効にするプロセスを示します。このアプローチを使用すると、一時的セキュリティ認証情報を作成して、Athena でクエリを実行する信頼できるユーザーに提供することができます。
一時的セキュリティ認証情報は、IAM ユーザーが使用できる長期アクセスキー認証情報と同様の働きをします。ただし、一時的セキュリティ認証情報には次の違いがあります。
Athena を使用すると、schema-on-read 分析によって、データレイク内の構造化または半構造化データセットから洞察を得ることができます。データレイクとは、ユビキタスでスケーラブルで信頼性の高いストレージであり、構造化データと非構造化データのすべてを活用することができます。顧客は、データレイク内のデータを照会するサーバーレスのアプローチを採用する傾向がますます高まっています。 Amazon S3 をデータレイクに使用する利点:
シナリオは、以下のとおりです。
この設定構成を有効にするには、CustomIAMRoleAssumptionCredentialsProvider カスタム認証情報プロバイダーを使用して、必要な認証情報を取得します。こうすることで、アカウント A の資格情報を使用してアカウント B で Athena クエリを実行できます。これは、次の図に示すように、クロスアカウントロールによって可能になります。
cross-account-trust.json ファイルの内容
policy.json ファイルの内容
IAM ポリシーの AmazonAthenaFullAccess および AmazonS3FullAccess を EC2AthenaInstanceProfileRole IAM ロールに、次のようにアタッチします。
こうしたアプローチにより、AWS リソースを保護するアクセスキーはアプリケーションで直接ハードコードされず、必要に応じて簡単に取り消すことができます。これを実現するために、AWS STS を使用して一時的な使用毎の認証情報を生成しました。
この記事で紹介したシナリオでは、SQL Workbench を使用しました。 ただし、Amazon Athena で他のすべての JDBC ドライバを使用する場合にも適用されます。さらに、Athena で AWS SDK を使用する場合も同様の方法が適用されます。
クエリをお楽しみください!
多くの組織では、集中化されたユーザー管理、特に Microsoft Active Directory または LDAP が標準となっています。 AWS リソースへのアクセスも例外ではありません。 Amazon Athena は、データレイク内のデータの迅速で費用効果の高いクエリで一般的である、Amazon S3 のデータ用のサーバーレスクエリエンジンです。 ユーザーまたはアプリケーションが Athena にアクセスできるようにするために、組織は AWS アクセスキーと適切なポリシーが適用されているアクセス秘密鍵を使用する必要があります。一貫性のある認証モデルを維持するために、組織はフェデレーテッドユーザーを使用して Athena の認証と承認を有効にする必要があります。
このブログ記事では、AWS Security Token Service (AWS STS) を使用してフェデレーテッドユーザーによるアクセスを有効にするプロセスを示します。このアプローチを使用すると、一時的セキュリティ認証情報を作成して、Athena でクエリを実行する信頼できるユーザーに提供することができます。
AWS STS での一時的セキュリティ認証情報
一時的セキュリティ認証情報により、保護された AWS リソースへのアクセスキーが適切にローテーションされます。したがって、潜在的なセキュリティリークが捕捉され、修正される可能性があります。AWS STS は、こうしたユーザー毎の一時的アクセスキーを生成します。一時的セキュリティ認証情報は、IAM ユーザーが使用できる長期アクセスキー認証情報と同様の働きをします。ただし、一時的セキュリティ認証情報には次の違いがあります。
- 短期間の使用のみを目的としています。 これらの認証情報は、数分から数時間、最大で 12 時間まで設定できます。有効期限が切れると、AWS はそれらを認識しなくなるか、それらの認証情報で行った API リクエストからの任意の種類のアクセスを許可します。
- ユーザーと共に保存されません。要求されたときに動的に生成され、ユーザーに提供されます。有効期限が切れた時または切れる前は、まだそれを行う許可がある場合、ユーザーは新しい認証情報を要求することができます。
フェデレーテッドアクセスの一般的なシナリオ
以下の一般的なシナリオは、組織が Athena へのフェデレーテッドアクセスを必要とする場合について説明します。- フェデレーションを使用しながら、Athena でクエリを実行する。グループは、Active Directory に保存されている権限を持つ SAML を使用して AWS へフェデレーションしながら、Athena でクエリを実行する必要があります。
- 組織内のユーザーのアカウント間で Athena へのアクセスを有効にする。1 つの AWS アカウントにアクセスできる組織内のユーザーは、別のアカウントで Athena クエリを実行する必要があります。
- データアプリケーションの Athena へのアクセスを有効にする。Amazon EC2 インスタンスにデプロイされたデータアプリケーションは、JDBC 経由で Athena クエリを実行する必要があります。
S3 でのデータレイクのクエリエンジンとしての Athena
Athena は、標準 SQL を使用して Amazon S3 で直接データを分析できるインタラクティブなクエリサービスです。JDBC と ODBC ドライバ、AWS SDK、または Athena コンソールを使用して、Athena にアクセスできます。Athena を使用すると、schema-on-read 分析によって、データレイク内の構造化または半構造化データセットから洞察を得ることができます。データレイクとは、ユビキタスでスケーラブルで信頼性の高いストレージであり、構造化データと非構造化データのすべてを活用することができます。顧客は、データレイク内のデータを照会するサーバーレスのアプローチを採用する傾向がますます高まっています。 Amazon S3 をデータレイクに使用する利点:
- 規模を問わず、あらゆるデータを低コストで効率的に活用および保存できる能力。
- 単一の場所で、関連するデータを検索および発見できる。
- 統合された一連のツールによる S3 のデータの分析。
ソリューションの概要
以下のセクションでは、この記事で前に紹介した一般的なシナリオを有効にする方法について説明します。まず、Athena でクエリを実行するための SQL Workbench のダウンロード、インストール、設定の方法を示します。次に、AWS STS をカスタム JDBC 認証情報プロバイダとともに使用して、承認されたユーザの一時的認証情報を取得する方法を示します。 これらの認証情報は Athena の JDBC ドライバーに渡され、SQL Workbench は承認されたクエリを実行できるようになります。シナリオは、以下のとおりです。
- フェデレーションを使用しながら、Athena でクエリを実行する。
- 組織内のユーザーのアカウント間で Athena へのアクセスを有効にする。
- データアプリケーションの Athena へのアクセスを有効にする。
ウォークスルー
このウォークスルーでは、Amazon CloudFront ログを照会するために作成されたサンプルテーブルを使用します。 それぞれのシナリオの後で、適切なアクセスが Athena に付与されていることを示しています。また、このウォークスルーでは、テスト用のテーブルがあることも前提としています。 テーブルの作成の詳細については、「Getting Started with Amazon Athena」を参照してください。シナリオ 1 および 2 の前提条件
- SQL Workbench をダウンロードしてインストールします。
- Athena カスタム認証情報プロバイダの .jar ファイルを、SQL Workbench がインストールされているのと同じコンピュータにダウンロードします。
- Amazon Athena JDBC ドライバーを、SQL Workbench がインストールされているのと同じコンピュータにダウンロードします。
- SQL Workbench で、[File, Connect] ウィンドウ、[Manage Drivers] と開きます。Athena ドライバーを選択し、ダウンロードした場所を指定して、Athena JDBC ドライバーとカスタム認証情報プロバイダーの 2 つのライブラリを追加します。
シナリオ 1: Active Directory による SAML フェデレーション
このシナリオでは、SAML コマンドラインツールを使用します。ID プロバイダーとの SAML ハンドシェイクを実行し、AWS STS から一時的セキュリティ認証情報を取得します。次に、取得したセキュリティ認証情報をカスタム認証情報プロバイダーに渡して、Athena でクエリを実行します。始める前に
- シナリオ 1 と 2 の前提条件を必ず守ってください。
- ADFS と SAML の統合を設定します。詳細は、「Enabling Federation to AWS Using Windows Active Directory, ADFS, and SAML 2.0」を参照してください。
- 以下の IAM ポリシーを ADFS-Production ロールに追加します。
- フェデレーテッド AWS CLI の設定。詳細は、「How to Implement a General Solution for Federated API/CLI Access Using SAML 2.0」を参照してください。
SAML フェデレーションされたユーザー ID を使用して Athena でクエリを実行する
- 前提条件の一部として設定されたフェデレーテッド AWS CLI スクリプトを実行します。有効なユーザー名とパスワードを使用してログインし、ADFS-Production ロールを選択します。その結果、一時的な access_key、secret_access_key および session_token が生成されます。これらは、次のような [saml] プロファイルの下にある「認証情報」ファイルに保存されます。
[saml]
output = json
region = us-east-1
aws_access_key_id = XXXXXXXXXXXXXXXXX
aws_secret_access_key = XXXXXXXXXXXXXXXXXXXXXX
aws_session_token = XXXXXXXXXXXXXXXXX
- SQL Workbench を使用して Athena でクエリを実行できるようにするには、Athena 接続を次のように設定します。
- [Extended Properties] を選択して、次のようにプロパティを入力します。
"AWSCredentialsProviderClass"="com.amazonaws.custom.athena.jdbc.CustomIAMRoleAssumptionSAMLCredentialsProvider"
"AWSCredentialsProviderArguments"="<access_key_id>, <secret_access_key>, <session token>"
"S3OutputLocation"="s3://<bucket where query results are stored>"
"LogPath"= "<local path on laptop, or pc where logs are stored>"
"LogLevel"= "<Log Level from 0 to 6>"
- [Test] を選択して、Athena に正常に接続できることを確認します。
- SQL Workbench でクエリを実行して、認証情報が正しく適用されていることを確認します。
シナリオ 2: クロスアカウントアクセス
このシナリオでは、アカウント A と呼ばれる 1 つのAWSアカウントのユーザーが、アカウント B と呼ばれる別のアカウントで Athena クエリを実行できるようにします。この設定構成を有効にするには、CustomIAMRoleAssumptionCredentialsProvider カスタム認証情報プロバイダーを使用して、必要な認証情報を取得します。こうすることで、アカウント A の資格情報を使用してアカウント B で Athena クエリを実行できます。これは、次の図に示すように、クロスアカウントロールによって可能になります。
始める前に
1.まだ実行していない場合は、シナリオ 1 および 2 の前提条件に従ってください。
- AWS CLI を使用して、アカウント B で AthenaCrossAccountRole という名前のロールを次のように定義します。
aws iam create-role --role-name AthenaCrossAccountRole --assume-role-policy-document file://cross-account-trust.json
{
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::<ACCOUNT-A-ID>:root"
},
"Action": "sts:AssumeRole"
}
}
]
}
- IAM ポリシーの AmazonAthenaFullAccess および AmazonS3FullAccess を AthenaCrossAccountRole IAM ロールに、次のようにアタッチします。
aws iam attach-role-policy --policy-arn arn:aws:iam::aws:policy/AmazonS3FullAccess --role-name AthenaCrossAccountRole
aws iam attach-role-policy --policy-arn arn:aws:iam::aws:policy/AmazonAthenaFullAccess --role-name AthenaCrossAccountRole
クロスアカウントロールを持つフェデレーテッドユーザー ID で、Athena でクエリを実行する
- 次の例に示すように、SQLWorkbench で新しい Athena データベース接続を設定します。
- [Extended Properties] を選択して、次の例のようにプロパティを入力します。この例では、アカウント A から IAM ユーザの AWS 認証情報 (AccessKey、SecretKey、Cross Account Role ARN) を設定します。
"AwsCredentialsProviderClass"="com.amazonaws.custom.athena.jdbc.CustomIAMRoleAssumptionCredentialsProvider"
"AwsCredentialsProviderArguments"="<aws_key_id>,<secret_key_id>,<cross Account Role ARN>"
"S3OutputLocation"="s3://<bucket where Athena results are stored>"
"LogPath"= "<local directory path on laptop, or pc where logs are stored>"
“LogLevel” = “Log Level from 1 to 6”
- [Test] を選択して、Athena に正常に接続できることを確認します。
- SQL Workbench でクエリを実行して、認証情報が正しく適用されていることを確認します。
シナリオ 3: EC2 インスタンスプロファイルロールの使用
このシナリオでは、Amazon EC2 インスタンスプロファイルロールを使用して一時的認証情報を取得します。 まず、次の例に示すように、AWS CLI を使用して EC2AthenaInstanceProfileRole IAM ロールを作成します。aws iam create-role --role-name EC2AthenaInstanceProfileRole --assume-role-policy-document file://policy.json
{
"Statement": [
{
"Action": "sts:AssumeRole",
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
}
}
]
}
aws iam attach-role-policy --policy-arn arn:aws:iam::aws:policy/AmazonAthenaFullAccess --role-name EC2AthenaInstanceProfileRole
aws iam attach-role-policy --policy-arn arn:aws:iam::aws:policy/AmazonS3FullAccess --role-name EC2AthenaInstanceProfileRole
始める前に
- Windows 用の Amazon EC2 インスタンスを起動し、前のステップで作成した InstanceProfile ロールをアタッチします。
aws ec2 run-instances --image-id <use Amazon EC2 on Windows 2012 AMI Id for your region> --iam-instance-profile 'Arn=arn:aws:iam::<your_aws_account_id>:instance-profile/EC2AthenaInstanceProfileRole' --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=AthenaTest}]' --count 1 --instance-type t2.micro --key-name <your key> --security-group-ids <your_windows_security_group_id>
2. RDP を使用して Windows インスタンスにログインします。
3. Java 8をインストールし、SQL Workbench をダウンロードしてインストールします。
4. Athena JDBC ドライバーをダウンロードします。
EC2 インスタンスプロファイルロールを使用して Athena でクエリを実行する
1. SQL Workbench で、[File, Connect] ウィンドウ、[Manage Drivers] と開きます。次の例に示すように、前にダウンロードした Athena JDBC ドライバーへのパスを指定します。
- インスタンス認証情報プロバイダー、 InstanceProfileCredentialsProvider は Amazon Athena JDBC ドライバーに含まれています。SQL Workbench で、次のように Athena 接続を設定します。
- [Extended Properties] を選択して、次のようにプロパティを入力します。
"AwsCredentialsProviderClass"="com.simba.athena.amazonaws.auth.InstanceProfileCredentialsProvider"
"S3OutputLocation"="s3://<bucket where Athena results are stored>"
"LogPath"= "<local directory path on laptop, or pc where logs are stored>"
“LogLevel” = “Log Level from 0 to 6”
- [Test] を選択して、Athena に正常に接続できることを確認します。
- SQL Workbench でクエリを実行して、認証情報が正しく適用されていることを確認します。
結論
この記事では、信頼できるユーザーが一時的セキュリティ認証情報を使用して Athena にアクセスできるようにする 3 つのシナリオを紹介しました。まず、ユーザー認証情報が Active Directory に保存されている SAML フェデレーションを使用しました。次に、カスタム認証情報プロバイダーライブラリを使用してクロスアカウントアクセスを有効にしました。さらに、EC2 インスタンスプロファイルロールを使用して、組織内のユーザーが Athena にアクセスするための一時的認証情報を提供しました。こうしたアプローチにより、AWS リソースを保護するアクセスキーはアプリケーションで直接ハードコードされず、必要に応じて簡単に取り消すことができます。これを実現するために、AWS STS を使用して一時的な使用毎の認証情報を生成しました。
この記事で紹介したシナリオでは、SQL Workbench を使用しました。 ただし、Amazon Athena で他のすべての JDBC ドライバを使用する場合にも適用されます。さらに、Athena で AWS SDK を使用する場合も同様の方法が適用されます。
クエリをお楽しみください!
コメント
コメントを投稿