【Informatica】外部シークレットマネージャーを使ったコネクタでCloud Storageに接続してみた
はじめに
データ事業本部の川中子(かわなご)です。
Informaticaで他クラウドサービスと接続するコネクタを作成する際、
基本的にはAPIキーやサービスアカウントキーなどの認証情報を直接設定する必要があります。
AWSのS3であればEC2のロールから別のロールをAssumeRoleする方法がありますが、
Google CloudのCloud Storageでは、サービスアカウントキーの発行が必須です。
キーを直接コネクタ設定に記載するのは、セキュリティ上のリスクがあるだけでなく、
定期的なキーのローテーション時にも一時的にジョブを停止するなどの管理負荷が発生します。
今回はInformaticaの外部シークレットマネージャー機能としてAWS Secrets Managerを利用し、
Google Cloud Storageにセキュアに接続する方法を検証してみました。
Informaticaの外部シークレットマネージャー連携とは
Informatica IICS(Intelligent Cloud Services)では、
コネクタの認証情報をIICSリポジトリに直接保存する代わりに、
外部のシークレットマネージャーから取得するように構成できます。
この機能を利用すると、以下のようなメリットがあります。
- 機密性の高い認証情報の管理を自社環境側に保持できる
- 複数環境にわたるシークレットの一元管理が可能になる
- コネクタやタスクに影響を与えずにシークレットのローテーションが可能になる
外部シークレットマネージャー
Informaticaでは以下の3つの外部シークレットマネージャーに対応しています。
AWS Secrets ManagerAzure Key VaultHashiCorp Vault
今回は、弊社のAWS環境ですぐに検証が可能だったAWS Secrets Managerを利用します。
前提条件
外部シークレットマネージャー連携を利用するにあたり、以下の前提条件があります。
- ランタイム環境内のすべての
Secure AgentがローカルマシンまたはVM上にインストールされていること - 各エージェントで
SecretManagerAppサービスが実行中であること Adminロール、またはSMS Manage ConnectionおよびSMS View Connectionのフィーチャー権限があること
サーバーレスランタイム環境では使用できない点に注意が必要です。
検証
以下の構成で検証していきます。
検証の構成
Google Cloud Storageを参照するためのコネクタに対して、
Secrets Managerに格納したサービスアカウントのキー情報を参照させます。
今回はSecure AgentをホストするEC2のあるアカウント(以降、エージェントアカウント)と、
Secrets Managerのあるアカウント(以降、シークレットアカウント)を分離した、
クロスアカウント構成で検証します。
最終的にGCSからGCSへのマッピングを作成して、データの読み書きができることを確認します。

手順1. Google Cloudでサービスアカウントを作成する
まずCloud Storageへのアクセス用のサービスアカウントを作成し、キー情報を取得します。
具体的な手順については本題ではないので割愛させていただきます。
ダウンロードしたJSONファイルには以下のような情報が含まれています。
{
"type": "service_account",
"project_id": "your-project-id",
"private_key_id": "xxxxx",
"private_key": "-----BEGIN PRIVATE KEY-----\nMIIEvQ...\n-----END PRIVATE KEY-----\n",
"client_email": "your-service-account@your-project.iam.gserviceaccount.com",
"client_id": "xxxxx",
...
}
このうち、InformaticaのGoogle Cloud Storage V2コネクタで必要になるのは以下の3つの値です。
| JSONのキー | GCS V2コネクタの設定項目 |
|---|---|
client_email |
Service Account ID |
private_key |
Service Account Key |
project_id |
Project ID |
手順2. シークレットアカウントでシークレットを作成する
シークレットアカウントにカスタマーマネージドのKMSキーを作成したうえで、
Secrets Managerでシークレットを作成します。
シークレットのタイプはその他のタイプのシークレットを選択し、
暗号化キーには作成したカスタマーマネージドKMSキーを指定します。
今回はService Account Keyのみシークレットから参照するため、
キー/バリューのペアとしてprivate_keyの値を格納します。
| キー | バリュー |
|---|---|
service_account_key |
サービスアカウントのprivate_keyの値 |
シークレット名は任意ですが、使用可能な文字は英数字と以下の文字列に限られます。
(/、_、+、=、.、@、-)
手順3. シークレットアカウントにIAMロールを作成する
シークレットアカウントに、Secrets ManagerとKMSへのアクセス権限を持つIAMロールを作成します。
このロールをエージェントアカウントのEC2のIAMロールからAssumeRoleして利用します。
まず、以下の権限を持つIAMポリシーをロールにアタッチします。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"secretsmanager:GetSecretValue",
"secretsmanager:ListSecrets"
],
"Resource": "arn:aws:secretsmanager:<リージョン>:<シークレットアカウントID>:secret:*"
},
{
"Effect": "Allow",
"Action": "kms:Decrypt",
"Resource": "arn:aws:kms:<リージョン>:<シークレットアカウントID>:key/<KMSキーID>"
}
]
}
信頼ポリシーには、エージェントアカウントのEC2ロールからのAssumeRoleを許可します。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::<エージェントアカウントID>:role/<EC2のIAMロール名>"
},
"Action": "sts:AssumeRole"
}
]
}
手順4. エージェントアカウントのIAM設定
続いて、エージェントアカウント側の設定を行います。
EC2のIAMロールに、手順3で作成したシークレットアカウントのロールへのAssumeRole権限を付与します。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::<シークレットアカウントID>:role/<手順3で作成したロール名>"
}
]
}
手順5. InformaticaでSecret Vaultを有効化する
Informaticaの管理画面からシークレットマネージャー連携を有効化します。
管理者>設定ページを開くセキュリティタブを選択- 編集アイコンをクリック
シークレットVaultを有効にするを有効化- シークレットマネージャーの種類として
AWS Secrets Managerを選択 - 認証タイプとリージョンを設定
今回は認証タイプにロールベースのアクセスを選択し、
手順3で作成したシークレットアカウントのIAMロールのARNを指定しています。

AWS Secrets Managerの設定方法については、以下の公式ドキュメントに詳しく記載されています。
認証タイプは3つから選択できます。
| 認証タイプ | 概要 |
|---|---|
ロールベースのアクセス |
IAMロールのARNを指定してアクセス |
インスタンスプロファイル |
EC2インスタンスプロファイルの認証情報を使用 |
アクセスキー |
アクセスキーID+シークレットアクセスキーを指定 |
設定後、Vault接続のテストからテストを実施して接続を確認します。

手順6. GCS V2コネクタを作成する
Secret Vaultの有効化が完了したら、Google Cloud Storage V2コネクタを作成します。
管理者 > 接続から新しい接続を作成し、
接続タイプとしてGoogle Cloud Storage V2を選択します。
画面上部のシークレットコンテナの使用を有効化して、
Service Account KeyにはシークレットのARNの値を設定します。

今回はキー/バリュー形式でシークレットを格納しているので、ARNの後に:<キー名>を付与しています。
arn:aws:secretsmanager:<リージョン>:<シークレットアカウントID>:secret:<シークレット名>-<サフィックス>:service_account_key
手順7. マッピングを作成して動作確認する
最後にGCSからGCSへのマッピングを作成して、実際にデータの読み書きができることを確認します。
ソースのバケットにテスト用のCSVファイルを配置しておきます。

テスト用のマッピングでは、ソースとターゲットを以下のように設定しています。
- ソース:
cm-informatica-sm-test-20250209/input/test_csv.csv - ターゲット:
cm-informatica-sm-test-20250209/output/output.csv

実際にジョブを実行すると、ターゲットフォルダにoutput.csvが出力されました。

まとめ
InformaticaのCloud Storage接続にAWS Secrets Manager連携を使用することで、
サービスアカウントのキー情報を安全に管理しながら接続できることが分かりました。
外部のシークレットマネージャー連携を利用することで、複数の認証情報を一元的に管理できます。
またキーのローテーション時にもシークレットマネージャー側を更新するだけで、
Informatica側のアセットへの影響を最小限に抑えられることも大きなメリットです。
Cloud Storageの利用時、外部シークレットマネージャーが利用できる環境なら、
積極的に使用することが推奨される構成だと思います。
本記事が少しでも参考になれば幸いです。
最後まで閲覧いただきありがとうございました。






