【Informatica】外部シークレットマネージャーを使ったコネクタでCloud Storageに接続してみた

【Informatica】外部シークレットマネージャーを使ったコネクタでCloud Storageに接続してみた

2026.02.09

はじめに

データ事業本部の川中子(かわなご)です。

Informaticaで他クラウドサービスと接続するコネクタを作成する際、
基本的にはAPIキーやサービスアカウントキーなどの認証情報を直接設定する必要があります。

AWSのS3であればEC2のロールから別のロールをAssumeRoleする方法がありますが、
Google CloudのCloud Storageでは、サービスアカウントキーの発行が必須です。

キーを直接コネクタ設定に記載するのは、セキュリティ上のリスクがあるだけでなく、
定期的なキーのローテーション時にも一時的にジョブを停止するなどの管理負荷が発生します。

今回はInformaticaの外部シークレットマネージャー機能としてAWS Secrets Managerを利用し、
Google Cloud Storageにセキュアに接続する方法を検証してみました。

Informaticaの外部シークレットマネージャー連携とは

Informatica IICS(Intelligent Cloud Services)では、
コネクタの認証情報をIICSリポジトリに直接保存する代わりに、
外部のシークレットマネージャーから取得するように構成できます。

https://docs.informatica.com/cloud-common-services/administrator/current-version/organization-administration/secrets-manager.html

この機能を利用すると、以下のようなメリットがあります。

  • 機密性の高い認証情報の管理を自社環境側に保持できる
  • 複数環境にわたるシークレットの一元管理が可能になる
  • コネクタやタスクに影響を与えずにシークレットのローテーションが可能になる

外部シークレットマネージャー

Informaticaでは以下の3つの外部シークレットマネージャーに対応しています。

  • AWS Secrets Manager
  • Azure Key Vault
  • HashiCorp 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へのマッピングを作成して、データの読み書きができることを確認します。

1770613417129

手順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で作成したロール名>"
        }
    ]
}

https://docs.informatica.com/cloud-common-services/administrator/current-version/organization-administration/general-and-security-settings/secrets-manager-configuration/aws-secrets-manager-configuration/cross-account-access-configuration-for-aws-secrets-manager.html

手順5. InformaticaでSecret Vaultを有効化する

Informaticaの管理画面からシークレットマネージャー連携を有効化します。

  1. 管理者 > 設定ページを開く
  2. セキュリティタブを選択
  3. 編集アイコンをクリック
  4. シークレットVaultを有効にするを有効化
  5. シークレットマネージャーの種類としてAWS Secrets Managerを選択
  6. 認証タイプとリージョンを設定

今回は認証タイプにロールベースのアクセスを選択し、
手順3で作成したシークレットアカウントのIAMロールのARNを指定しています。

1770616170555

AWS Secrets Managerの設定方法については、以下の公式ドキュメントに詳しく記載されています。

https://docs.informatica.com/cloud-common-services/administrator/current-version/organization-administration/general-and-security-settings/secrets-manager-configuration/aws-secrets-manager-configuration.html

認証タイプは3つから選択できます。

認証タイプ 概要
ロールベースのアクセス IAMロールのARNを指定してアクセス
インスタンスプロファイル EC2インスタンスプロファイルの認証情報を使用
アクセスキー アクセスキーID+シークレットアクセスキーを指定

設定後、Vault接続のテストからテストを実施して接続を確認します。

1770616282601

手順6. GCS V2コネクタを作成する

Secret Vaultの有効化が完了したら、Google Cloud Storage V2コネクタを作成します。

管理者 > 接続から新しい接続を作成し、
接続タイプとしてGoogle Cloud Storage V2を選択します。

https://docs.informatica.com/integration-cloud/data-integration-connectors/current-version/google-cloud-storage-v2-connector/google-cloud-storage-v2-connections/google-cloud-storage-v2-connection-properties.html

画面上部のシークレットコンテナの使用を有効化して、
Service Account KeyにはシークレットのARNの値を設定します。

1770617887665

今回はキー/バリュー形式でシークレットを格納しているので、ARNの後に:<キー名>を付与しています。

arn:aws:secretsmanager:<リージョン>:<シークレットアカウントID>:secret:<シークレット名>-<サフィックス>:service_account_key

https://docs.informatica.com/cloud-common-services/administrator/current-version/organization-administration/general-and-security-settings/secrets-manager-configuration/configuring-a-connection-to-use-the-secrets-manager.html

手順7. マッピングを作成して動作確認する

最後にGCSからGCSへのマッピングを作成して、実際にデータの読み書きができることを確認します。

ソースのバケットにテスト用のCSVファイルを配置しておきます。

1770621338369

テスト用のマッピングでは、ソースとターゲットを以下のように設定しています。

  • ソース:cm-informatica-sm-test-20250209/input/test_csv.csv
  • ターゲット:cm-informatica-sm-test-20250209/output/output.csv

1770620883743

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

1770621365455

まとめ

InformaticaのCloud Storage接続にAWS Secrets Manager連携を使用することで、
サービスアカウントのキー情報を安全に管理しながら接続できることが分かりました。

外部のシークレットマネージャー連携を利用することで、複数の認証情報を一元的に管理できます。
またキーのローテーション時にもシークレットマネージャー側を更新するだけで、
Informatica側のアセットへの影響を最小限に抑えられることも大きなメリットです。

Cloud Storageの利用時、外部シークレットマネージャーが利用できる環境なら、
積極的に使用することが推奨される構成だと思います。

本記事が少しでも参考になれば幸いです。
最後まで閲覧いただきありがとうございました。

この記事をシェアする

FacebookHatena blogX

関連記事