Amazon Web Services ブログ

【寄稿】Amazon Redshift Serverlessへのセキュアなアクセス

この投稿はアクセンチュア株式会社 テクノロジーコンサルティング本部所属のマネージャー 竹内 誠一 氏に、Amazon Redshift Serverlessへのセキュアなアクセスの検証結果について寄稿いただいたものです。

本投稿は、Amazon Redshift Serverlessに保管する機密情報へのアクセスを制御したいという要件に対する解決策の一案をご紹介します。

あるお客様でデータ管理プラットフォームの候補としてAmazon Redshift Serverlessの機能を評価する機会があり、その評価項目の一つに上記の要件がありました。Amazon Redshift Serverlessへのアクセス経路はひとつではなく、アクセス制御の方法も様々考えられるので、この要件の考慮点は意外と多岐にわたります。少し特殊な要件かもしれませんが、考察自体は有用と考えたのでブログに整理して共有いたします。

このケースで求められるアクセス制御は、限られたユーザが特定の場所からSQLのクエリを投入した場合のみAmazon Redshift Serverlessに保管された機密情報にアクセスできることであり、以下に列挙する要件を満たす必要があります。

  • 機密情報は、アクセス権限を付与されたユーザ（特権ユーザ）が、ハイセキュリティエリアに設置された端末を使用した場合のみ照会できる
  • 機密情報を含む照会リクエストや応答データの経路は閉域網（専用線 or VPN経由）に限定する
  • ユーザ認証はデータベースユーザ/パスワード認証ではなく、IdPとのSAMLシングルサインオンとする

構成図はこのようになります。

構成図

以下、「クエリの投入手段」「アクセス経路の限定」「アクセスユーザの限定」「SAMLシングルサインオン構成時の注意点」の各観点で考察します。

1. クエリの投入手段

Amazon Redshift ServerlessにSQLコマンド（クエリ）を投入する手段を列挙してみます。

  1. Amazon Redshift Query Editor V2
  2. JDBC/ODBC
  3. Amazon Redshift Data API
  4. AWS CLI redshift-data execute-statementコマンド
  5. RSQL、PSQL
  6. SQL Workbench/J、DBeaver等のGUIツール

このうち4のAWS CLIは背後でData APIを使用しており、5と6は背後でJDBCやODBCのエンドポイントを使用しているので、アクセス制御の観点では1、2、3を評価すれば十分と考えました。

比較評価した結果をまとめたのが下表です。

 

Query Editor V2 JDBC/ODBC Data API
機密情報は、アクセス権限を付与されたユーザが、ハイセキュリティエリアに設置された固定端末を使用した場合のみ照会できる 可能 可能 可能
機密情報を含む照会リクエストや応答データの経路は閉域網に限定する 不可（画面へのアクセスはインターネット経由のみ） 可能 可能
ユーザ認証はAmazon Redshift Serverless独自の認証ではなく、IdPとのSAMLシングルサインオンとする 可能 可能 AWS CLIを使用したとしてもプログラム開発が避けられない
評価 不可 推奨 難易度高

Query Editor V2はブラウザで動作するGUIベースの高機能なSQLクライアントで、アクセスポイントはAWSコンソールと同様にインターネット上にあります。通信は常にTLSで暗号化されるため安全ですが、企業のセキュリティ規定等でデータ経路を閉域網に限定されている場合はQuery Editor V2は候補から外さざるを得ません。

Data APIは任意のアプリケーションやプログラムからRedshiftデータへアクセスするものですが、AWS CLIからクエリを投入する場合にも背後で使用されています。AWS CLIを使えばプログラムを開発せずにData API経由でクエリを投入できます。しかしAWS CLIはSAMLシングルサインオンに対応していないため、AWS CLIとは別の仕組みでSAMLシングルサインオンを実行し、得られた認証情報をAWS CLIに連携しなければなりません。結局そのためのプログラムやシェルスクリプト等の開発は避けられず、難易度は高めです。

一方JDBC/ODBCの場合は、Amazon RedshiftのJDBC/ODBCドライバがSAMLシングルサインオンに対応しており、認証情報を取得し連携するためのプログラム開発は必要ありません。ここまでの考察を踏まえて、次章以降ではJDBC/ODBCを利用する方法を深堀していくことにします。

2. アクセス経路の限定

2-1. JDBC/ODBC以外の手段を排除

JDBC/ODBC以外の手段でAmazon Redshift Serverlessにアクセスできる可能性を潰しておきます。JDBC/ODBC以外の手段にはQuery Editor V2とData APIがありますが、これらはIAMで排除できます。

まずQuery Editor V2ですが、Query Editor V2の利用のためにはIAM ポリシーでsqlworkbench:プレフィックスのアクションの許可が必要です。したがって機密情報へのアクセス権限を持つユーザ（特権ユーザ）のIAMロールに、sqlworkbench:プレフィックスのアクションを許可するポリシーを割り当てないようにします。

同様にData APIの利用のためには、IAMポリシーでredshift-data:プレフィックスのアクションの許可が必要です。特権ユーザにData APIを使用させないため、IAMロールにredshift-data:プレフィックスのアクションを許可するポリシーを割り当てないようにします。

2-2. エンドポイントをVPCに限定

Amazon Redshift ServerlessのエンドポイントをVPCに限定します。

Amazon Redshift Serverlessのエンドポイントはワークグループで管理しており、ひとつ以上のVPCとの関連付けと、インターネットからのアクセスの可否を定義できます。ワークグループの「Publicly accessible」をOffにすることでJDBC/ODBC用エンドポイントへのアクセスはVPC経由に限定されます。

更にVPCエンドポイントにアタッチしたセキュリティグループで、インバウンドのソースIPアドレスをハイセキュリティエリアのCIDRブロックに限定します。

これでJDBC/ODBCへのアクセスは、ハイセキュリティエリアから閉域網経由で入ってくるリクエストに限定できます。

2-3. SAML IdPとの通信経路の考慮点

SAML IdPとしてAzure AD等のクラウドサービスを使用する場合、ユーザID/パスワードを入力してSAMLアサーションを取得するための通信はインターネットを経由することになります。IdPによっては閉域網接続をサポートしている場合もあるので、IdPとの通信も閉域網に限定する必要がある場合はIdPの仕様や現在の設定を確認することをお勧めします。

2-4. GetCredentials API呼び出しの通信経路の考慮点

JDBC/ODBCドライバは、SAMLシングルサインオンによる接続要求を処理する際に、Amazon Redshift ServerlessのGetCredentials APIを呼び出して一時的なデータベース認証情報を取得します。このAPIのサービスエンドポイントはredshift-serverless.｛リージョン名｝.amazonaws.comというドメイン名なのですが、このブログ執筆時点（2023年3月）ではこのサービスエンドポイントはVPCエンドポイント（PrivateLink）をサポートしていません。サービスエンドポイントはグローバルIPアドレスを持ち、GetCredentials API呼び出しの通信はインターネットを経由することになります。

この通信がインターネットを経由する可能性を排除したい場合は、Amazon Direct Connectのパブリック仮想インターフェース（VIF）の検討をお勧めします。 これによりグローバルIPアドレスを持つサービスエンドポイントへの通信を閉域網経由とすることができます。

3. アクセスユーザの限定

前章で、JDBC/ODBCのエンドポイントを特定のVPCに限定し、ハイセキュリティエリアからのアクセスしか受け付けないようにしました。またJDBC/ODBC以外の手段によるアクセスも許可しないようにしました。

次は、機密情報へのアクセス権限を持つユーザ（以下「特権ユーザ」と呼ぶことにし、それ以外を「一般ユーザ」と呼ぶことにします）がハイセキュリティエリアからアクセスしたときだけ機密情報にアクセスできるための条件を考えます。

考慮点は次の２点です。

  1. 一般ユーザが機密情報にアクセスできないこと
  2. 特権ユーザがハイセキュリティエリア以外の場所から機密情報にアクセスできないこと

3-1.  一般ユーザが機密情報にアクセスできないこと

Amazon Redshift Serverlessデータベースに格納された機密情報に対するアクセスは、SQLのGRANTまたはREVOKEコマンドを使用して制御します。Amazon Redshift ServerlessではSQLのCREATE USERコマンドでIAMロールをデータベースユーザとして登録できるので、GRANTまたはREVOKEコマンドがアクセス権限を付与または剥奪する対象としてIAMロールも選択できます。

一般ユーザのIAMロールに機密情報へのアクセス権限を付与しなければ、どのような経路を経てデータベースに接続してきても一般ユーザは機密情報にアクセスできません。一般ユーザから機密情報へのアクセス制御はこれで十分です。

3-2.  特権ユーザがハイセキュリティエリア以外の場所から機密情報にアクセスできないこと

特権ユーザにはGRANTコマンドで機密情報へのアクセス許可を付与しますが、GRANTの許可にアクセス経路の条件を持たせることはできません。したがってハイセキュリティエリア以外の場所から機密情報にアクセスさせないためには、セキュリティエリア以外の場所でSQLコマンドの投入を防止しなければなりません。

2章で述べたように、アクセス経路のうちQuery Editor V2とData APIについてはIAMロールで制御できるので、特権ユーザのIAMロールにはこれらのアクセス経路に必要なアクションを許可しないようにします。

残る経路はJDBC/ODBCですが、以下の２点の理由によりJDBC/ODBCのVPCエンドポイントへのアクセスを場所で制御することが困難なため、ハイセキュリティエリア以外の場所からJDBC/ODBCのVPCエンドポイントへの経路を設けないことを現時点ではお勧めします。例えば、機密情報はハイセキュリティエリアからJDBC/ODBC経由でアクセスし、それ以外のデータは任意の場所からQuery Editor V2でアクセスするという使い分けが考えられます。

理由１：Amazon Redshift ServerlessのJDBC/ODBCのVPCエンドポイントへのアクセスはIAMで制御できません。例えば特権ユーザのIAMロールのIDベース・ポリシーでJDBC/ODBCのVPCエンドポイントをリソースとして指定し、そのリソースへのアクションを許可・拒否するポリシーを記述することはできません。リソースベース・ポリシーもサポート対象外です。

理由２：JDBCドライバはデータベースに接続する直前にAmazon Redshift ServerlessのGetCredentials APIを呼び出して一時的なデータベース認証情報を取得しています。このAPI呼び出しをIAMで制御することは可能ですが、呼び出し場所を条件として制御する有効な手段がありません。

例えばIAMポリシーのaws:SourceIp条件キーを使えば呼び出し元のIPアドレスを条件として制御できそうですが、通信がリバースプロキシを経由してインターネットに出ていく場合を考えると、リバースプロキシサーバのグローバルIPアドレスが呼び出し元のIPアドレスになるため個々の端末を区別できません。パブリック仮想インターフェースを使う場合でも、通信がNATを経由する際にNATのグローバルIPアドレスが呼び出し元のIPアドレスになります。

APIのサービスエンドポイントがVPCエンドポイントをサポートしていれば、例えばaws:SourceVpce条件キーを使用して、特権ユーザがアクセスするVPCエンドポイントと一般ユーザがアクセスするVPCエンドポイントを分ける方法が考えられます。現時点ではAmazon Redshift ServerlessのAPIサービスエンドポイントはVPCエンドポイントをサポートしていませんが、将来のサポートに期待します。

4. SAMLシングルサインオン構成時の注意点

SAMLシングルサインオンでRedshiftにアクセスするための設定方法は、以下のAWSドキュメントやAWSブログで詳細に説明されています。

これらの説明はAmazon Redshift Provisionedクラスタを対象としていますが、Amazon Redshift Serverlessでも同じ方法で動作確認できました。ただし1点注意が必要な部分がありましたのでご紹介しておきます。動作確認に使用したJDBCドライバのバージョンはV2.1.0.9です。

要注意箇所はAzure ADにReply URLとして”http://localhost/redshift/”を指定する部分です。これはJDBCドライバがSAMLアサーションを受け取るためのURLですが、任意のポート番号を設定できるようになっていた上にデフォルトが80番ではなくなったので”http://localhost/redshift/”では接続できません。

対策としては次の２つの方法が考えられます。

  1. Reply URLは”http://localhost:{ポート番号}/redshift/”とし、JDBCドライバにポート番号を明示的に指定する
  2. Reply URLは”http://localhost/redshift/”のままで、JDBCドライバにポート番号80を明示的に指定する

JDBCドライバのポート番号はlisten_portパラメータで設定します。SQL Workbench/Jではパラメータはextended propertiesで設定します。以下に設定例を添付します。

設定例

5. まとめ

本ブログでは、Amazon Redshift Serverlessに保管する機密情報へのアクセスを制御したいという課題を取り上げ、ハイセキュリティエリア専用のJDBC/ODBCエンドポイントを設けることで、冒頭に提示した要件を満たすことを示しました。

この構成ではSAMLシングルサインオン、AWSクラウド内のデータアクセス経路の選択、Amazon Redshift Serverlessデータベース内のデータアクセス権限を、IAMロールを軸として一貫して制御できます。セキュリティに対するさまざまな要求を一貫性のある設計・運用に落とし込めることはAWS IAMのアーキテクチャの優れた部分と言えるでしょう。

今後の改善に期待する点としては、redshift-serverless APIサービスエンドポイントのVPCエンドポイントサポートを挙げておきます。今回の要件において必須ではありませんでしたが、APIサービスエンドポイントがVPCエンドポイントをサポートすることによりセキュアな経路選択のパターンを増やせます。そこまでのニーズは少ないかもしれませんが、Amazon Redshift Provisionedクラスタでは対応できているので、Amazon Redshift Serverlessもいずれキャッチアップしてくれると期待しています。

サーバーレス型の採用によりインフラ周りを意識せず手軽に使えるようになり、より多くの人にデータを届けられるようになったAmazon Redshift Serverlessのさらなる進化に期待しています。

著者について

竹内 誠一

竹内 誠一

アクセンチュア株式会社
マネジャー　テクノロジーコンサルティング本部
インテリジェントクラウド アンド インフラストラクチャー グループ所属