目次
DBユーザーとIAMユーザーの権限を分けることでセキュリティ強化を行う
AWSのビッグデータ用DBのAmazon Redshift(以下、Redshift)に大量データを登録する場合は、クラウドストレージのAmazon S3(以下、S3)にインポートするデータをアップロードし、Redshiftの専用コマンドでインポートを実行していました。このインポートを実行するためのコマンドの中には、S3へアクセスするためのキー情報を入力する必要があり、セキュリティの面で様々な問題がありました。
今回は、2016年03月29日にリリースされたRedshiftクラスターにIAMロールを適用する方法でRedshiftのインポート／エクスポート処理のセキュリティを強化する方法についてご紹介したいと思います。
従来の方法のセキュリティの問題点
従来の方法
RedshiftからS3経由でデータファイルをアップロードする時に、下記のようにインポートコマンド(COPYコマンド)の中にS3へのアクセス権を持ったAWS Identity and Access Management(以下、IAM)ユーザーのアクセスキーIDとシークレットアクセスキーを指定する必要がありました。
|
1 2 |
COPY m_calendar FROM 's3://backet_name/calendar.csv' CREDENTIALS 'aws_access_key_id=XXXXXXXXXX;aws_secret_access_key=XXXXXXXXXX' delimiter ','; |
このIAMユーザーのアクセスキーIDとシークレットアクセスキーは、Redshiftのインポート／エクスポートのだけではなく、S3へデータファイルのアップロード／ダウンロードでも同様の情報で行うことができます。
従来の方法の問題点
上記のようにRedshiftのインポート／エクスポートとS3のデータファイルのアップロード／ダウンロードを同様の認証情報で行えて便利な反面、インポート／エクスポートの命令を実行する度にアクセスキーIDとシークレットアクセスキーを入力する必要があり、これらの情報が漏れる危険性が高くなってしまいました。また、RedshiftのDBユーザー権限に関係なく、エクスポート命令が実行できてしまうのも問題です。
RedshiftのDBユーザーによってインポート／エクスポート権限を付与する
IAMロールを使った方法
IAMロールを使ったインポート／エクスポートの特徴として、Redshiftのインポート、またはエクスポートのコマンド実行の際にアクセスキーIDとシークレットアクセスキーを記入する必要が無い事です。(参考：AWS | COPY – Amazon Redshift)
|
1 2 |
COPY m_calendar FROM 's3://backet_name/calendar.csv' CREDENTIALS 'aws_iam_role=arn:aws:iam::[AWSアカウントID]:role/S3FullAccessRole' delimiter ','; |
アクセスキーIDとシークレットアクセスキーがあれば、そのIAMユーザーに付与されたS3などの様々なAWSサービスを利用することができます。しかし、IAMロール名が分かったところで、AWSサービスは利用することができません。IAMロールを使ったのインポート、またはエクスポートは、「ログインしているRedshiftのDBユーザー ＋ IAMロール名」の2つの情報を使って、初めて実行することができます。
IAMロールでDBユーザーとS3の橋渡しを行う
これから上記のCOPYコマンドで使用したIAMロール「S3FullAccessRole」の作成方法について解説したいと思います。(参考：AWS | Authorizing Amazon Redshift to Access Other AWS Services On Your Behalf – Amazon Redshift)
最初に下記のようにIAMロールに対して、S3のアクセス権を持ったポリシーをアタッチします。
次に信頼関係の設定で接続するDBユーザーを設定します。
上記画面の「信頼関係の編集」ボタンからアクセス権をJSON形式で設定します。この様に”sts:ExternalId”の中にRedshiftへのインポート、またはエクスポートを許可する「RedshiftのDBユーザー」をリスト形式で登録します。例えば、AWSアカウントIDが”123456789012″、クラスター名が”testdb”、ユーザー名が”superuser”の場合、”arn:aws:redshift:ap-northeast-1:123456789012:dbuser:testdb/superuser”のようになります。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "redshift.ap-northeast-1.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "StringLike": { "sts:ExternalId": [ "arn:aws:redshift:ap-northeast-1:[AWSアカウントID]:dbuser:[クラスター名]/[DBユーザーID]", "arn:aws:redshift:ap-northeast-1:[AWSアカウントID]:dbuser:[クラスター名]/[DBユーザーID]", "arn:aws:redshift:ap-northeast-1:[AWSアカウントID]:dbuser:[クラスター名]/[DBユーザーID]", "arn:aws:redshift:ap-northeast-1:[AWSアカウントID]:dbuser:[クラスター名]/[DBユーザーID]", "arn:aws:redshift:ap-northeast-1:[AWSアカウントID]:dbuser:[クラスター名]/[DBユーザーID]" ] } } } ] } |
最後にIAMロールを付与したいRedshiftのクラスターに対して、「Manage IAM Roles」ボタンをクリックして、作成したIAMロールを付与します。
IAMユーザーのアクセスキーIDとシークレットアクセスキーは見えないようにする事が重要
IAMユーザーのアクセスキーIDとシークレットアクセスキーは、20桁と40桁の英数字の組合せで作成されているため、記憶する事は困難です。しかし、開発資産だからと言って、Redshiftへのインポートコマンドなどをテキストとしてプロジェクト共有のファイルサーバーなどに保存していては、何の意味もありません。
IAMには、今回ご紹介したRedshiftのDBユーザー権限による制限の他に、アクセス先IPアドレス、AWSサービスなど様々なアクセス制限を持たせることができます。そのため、AWSの標準設定のセキュリティを使うのではなく、クライアントやプロジェクト体系に合わせた最適なセキュリティを組み合わせる必要があります。
