接続の確立

接続プロファイルの設定

［CData］リボンから［データの取得］をクリックし、［取得元：PostgreSQL］> 設定済みの接続を選択してCData クエリウィンドウを起動します。新しい接続を設定するには、［新しいPostgreSQL 接続］をクリックします。ここでは、接続の設定、接続のテスト、および接続プロファイルの保存を行うことができます。

PostgreSQL への接続

PostgreSQL に接続するには、通常次の接続プロパティが必要です。

Server：PostgreSQL データベースをホスティングしているサーバーのホスト名またはIP アドレス。
User：PostgreSQL サーバーに認証する際に使われるユーザー。

また、オプションで以下を設定することもできます。

Database：PostgreSQL サーバーに接続する場合のデータベース。設定されていない場合は、ユーザーのデフォルトデータベースが使用されます。
Port：PostgreSQL データベースをホスティングしているサーバーのポート。 5432がデフォルトです。

PostgreSQL への認証

PostgreSQL は、以下の方法による認証をサポートしています。

標準
pg_hba.conf
- MD5
- SASL
Entra ID（Azure AD）
Azure サービスプリンシパル
- AzureServicePrincipal
- AzureServicePrincipalCert
Azure AD Password
Azure AD MSI
GCP サービスアカウント
Amazon Web Services
Kerberos

標準

他のスキームを選択しない限り、本製品がPostgreSQL サーバーに接続する際に使用するデフォルトの認証メカニズムはPassword です。

標準認証を使用する場合、PostgreSQL にログイン資格情報で接続するにはAuthScheme をPassword に設定します。

そして、認証するために、認証するユーザーに紐づいたPassword を設定します。

pg_hba.conf 認証スキーム

本製品がサポートするPassword 認証スキームのサブタイプは、PostgreSQL サーバー上のpg_hba.conf ファイルで有効化する必要があります。

PostgreSQL サーバーでの認証の設定について、詳しくはPostgreSQL ドキュメントを参照してください。

MD5

本製品は、MD5 でパスワードを検証することで認証できます。pg_hba.conf ファイルのauth-method をmd5 に設定し、この認証方法を有効にする必要があります。

SASL

本製品は、SASL（特にSCRAM-SHA-256）でパスワードを検証することで認証できます。pg_hba.conf ファイルのauth-method をscram-sha-256 に設定し、この認証方法を有効にする必要があります。

Entra ID（Azure AD）

Microsoft Entra ID は、マルチテナント型のクラウドベースのID およびアクセス管理プラットフォームです。 OAuth ベースの認証フローに対応しており、ドライバーによるPostgreSQL エンドポイントへのセキュアなアクセスを実現します。

Web アプリケーションを介したEntra ID への認証には、必ずはじめにカスタムOAuth アプリケーションを作成して登録する必要があります。これにより、アプリケーションは独自のリダイレクトURI を定義し、クレデンシャルのスコープを管理し、組織固有のセキュリティポリシーに準拠することができるようになります。

カスタムOAuth アプリケーションの作成および登録方法の詳細については、Entra ID（Azure AD）アプリケーションの作成を参照してください。

AuthScheme をAzureAD に設定した後の認証手順は、環境によって異なります。デスクトップアプリケーション、Web ベースのワークフロー、またはヘッドレスシステムから接続する方法の詳細については、以下のセクションを参照してください。

デスクトップアプリケーション

デスクトップアプリケーションでは、ドライバーに組み込まれたOAuth アプリケーション、またはMicrosoft Entra ID に登録されたカスタムOAuth アプリケーションのいずれかを使用して認証を行うことができます。

オプション1：組み込みOAuth アプリケーションの使用

これはドライバーに含まれている、事前登録済みのアプリケーションです。セットアップが簡単で、独自の認証情報を登録する必要がないため、開発環境、単一ユーザー向けツール、または迅速かつ簡単な認証が求められる構成に最適です。

次の接続プロパティを設定します。

AuthScheme：AzureAD
InitiateOAuth：
- GETANDREFRESH – 初回ログイン時に使用します。ログインページを起動し、トークンを保存します。
- REFRESH – すでに有効なアクセストークンおよびリフレッシュトークンを取得している場合は、この設定を使用します。保存されたトークンを再利用するため、ユーザーに再度プロンプトを表示することはありません。

接続時には、ドライバーは既定のブラウザでMicrosoft Entra のサインインページを開きます。サインインしてアクセスを許可すると、ドライバーはアクセストークンおよびリフレッシュトークンを取得し、OAuthSettingsLocation で指定されたパスに保存します。

オプション2：カスタムOAuth アプリケーションの使用

組織でセキュリティポリシーの管理、リダイレクトURI の設定、アプリケーションのブランディングなど、より高度な制御が必要な場合は、代わりにMicrosoft Entra ID にカスタムOAuth アプリケーションを登録し、接続時にその値を指定することができます。

登録時に、以下の値を記録してください。

OAuthClientId：カスタムOAuth アプリケーションの登録時に生成されたクライアントId。
OAuthClientSecret：カスタムOAuth アプリケーションの登録時に生成されたクライアントシークレット。
CallbackURL：アプリケーション登録時に定義したリダイレクトURI。

カスタムOAuth アプリケーションの登録とリダイレクトURI の設定方法の詳細については、Entra ID（Azure AD）アプリケーションの作成を参照してください。

次の接続プロパティを設定します。

AuthScheme： AzureAD
InitiateOAuth：
- GETANDREFRESH – 初回ログイン時に使用します。ログインページを起動し、トークンを保存します。
- REFRESH – すでに有効なアクセストークンおよびリフレッシュトークンを取得している場合は、この設定を使用します。保存されたトークンを再利用するため、ユーザーに再度プロンプトを表示することはありません。
OAuthClientId：カスタムOAuth アプリケーションの登録時に生成されたクライアントId。
OAuthClientSecret：カスタムOAuth アプリケーションの登録時に生成されたクライアントシークレット。
CallbackURL：アプリケーション登録時に定義したリダイレクトURI。

認証後、トークンはOAuthSettingsLocation に保存されます。これらの値はセッションをまたいで保持され、アクセストークンの有効期限が切れた際に自動的に更新されるため、次回以降の接続時に再度ログインする必要はありません。

Note： Azure PostgreSQL Flexible サーバーはサポート対象外です。Azure PostgreSQL Single Server インスタンスのみサポートされます。

Azure PostgreSQL インスタンスでActive Directory 管理者が設定されていることを確認します（Active Directory 管理者 -> 管理者の設定）。

次に、接続するには以下を設定します。

User：Azure PostgreSQL サーバーへのアクセス権を付与したAzure Active Directory ユーザー。
AzureTenant：Azure 上のPostgreSQL への認証に使用するOAuth アプリの概要ページにある、Directory (tenant) ID。
Server：Azure PostgreSQL インスタンスの概要ページにある、Azure PostgreSQL のサーバー名。
Database：Azure PostgreSQL インスタンスで接続するデータベース。
Port：PostgreSQL データベースをホスティングしているサーバーのポート。 5432がデフォルトです。
OAuthClientId：Azure 上のPostgreSQL への認証に使用するOAuth アプリの概要ページにある、アプリケーション（クライアント）ID。
OAuthClientSecret：認証するOAuth アプリの証明書とシークレットページで生成されたクライアントシークレットの値。
CallbackURL：OAuth アプリの作成時に指定したリダイレクトURI。

Azure サービスプリンシパル

Note：Microsoft はAzure AD をEntra ID にリブランドしました。ユーザーがEntra ID 管理サイトを操作する必要があるトピックでは、Microsoft が使用している名称と同じものを使用します。ただし、名前または値が"Azure AD" を参照しているCData 接続プロパティは、依然として存在します。

サービスプリンシパルは、Microsoft Entra ID（Azure AD）アプリケーション内のセキュリティオブジェクトであり、そのアプリケーションが特定のテナント内で何を行えるかを定義します。サービスプリンシパルはEntra 管理センターで作成でき、Azure ポータルからもアクセス可能です。作成プロセスの過程で、サービスプリンシパルがクライアントシークレットまたは証明書のどちらを経由してEntra リソースにアクセスするかも指定します。

接続先のサービスによっては、テナント管理者がサービスプリンシパル認証を有効にするか、サービスプリンシパルを適切なロールまたはセキュリティグループに割り当てる必要があります。

サービスプリンシパルの権限は、特定のユーザーに紐づくのではなく、割り当てられたロールに基づきます。これらのロールは、アプリケーションがアクセスできるリソースと、実行できる操作を決定します。

サービスプリンシパルを使用して認証する場合、Entra ID（Azure AD）でのサービスプリンシパルアプリの作成で説明するようにEntra テナントにアプリケーションを登録する必要があります。

このサブセクションでは、接続前に設定する必要があるプロパティについて説明します。これらは、クライアントシークレットで認証するか、証明書で認証するかによって異なります。

クライアントシークレットによる認証

AuthScheme：AzureServicePrincipal。
AzureTenant：接続するAzure AD テナント。
OAuthClientId：アプリケーション設定のクライアントID。
OAuthClientSecret：アプリケーション設定のクライアントシークレット。
InitiateOAuth：GETANDREFRESH。InitiateOAuth を使うと、OAuth 交換の繰り返しや、手動でのOAuthAccessToken 設定を避けられます。

証明書による認証

AuthScheme：AzureServicePrincipalCert。
AzureTenant：接続するAzure AD テナント。
OAuthClientId：アプリケーション設定のクライアントId。
OAuthJWTCert：JWT 証明書のストア。
OAuthJWTCertType：JWT 証明書ストアの種類。
InitiateOAuth：GETANDREFRESH。InitiateOAuth を使うと、OAuth 交換の繰り返しや、手動でのOAuthAccessToken 設定を避けられます。

Azure Password

Azure 認証情報を使用してAzure Active Directory に直接認証するには、以下の接続プロパティを指定します：

AuthScheme：AzurePassword。
User：Azure への接続に使用するユーザーアカウント。
Password：Azure への接続に使用するパスワード。
AzureTenant：Azure 上のPostgreSQL への認証に使用するOAuth アプリの概要ページにある、Directory (tenant) ID。
Server：Azure PostgreSQL インスタンスの概要ページにある、Azure PostgreSQL のサーバー名。
Database：Azure PostgreSQL インスタンス上の接続先のデータベース。
Port：PostgreSQL データベースをホスティングしているサーバーのポート。 5432がデフォルトです。

GCP サービスアカウント

サービスアカウントを使用してPostgreSQL Google SQL Cloud Instance に認証するには、新しいサービスアカウントを作成し、アカウント証明書のコピーを用意する必要があります。サービスアカウントを持っていない場合は、Entra ID（Azure AD）アプリケーションの作成の手順に従って作成できます。 JSON ファイルの場合は、以下のプロパティを設定します。

AuthScheme：GCPServiceAccount。
InitiateOAuth：GETANDREFRESH。
OAuthJWTCertType：GOOGLEJSON。
OAuthJWTCert：Google が提供する.json ファイルへのパス。
OAuthJWTSubject（オプション）：この値は、サービスアカウントがGSuite ドメインの一部で、委任を有効にする場合にのみ設定します。このプロパティの値は、データにアクセスしたいユーザーのE メールアドレスでなければなりません。

PFX ファイルの場合は、代わりに以下のプロパティを設定します。

AuthScheme：GCPServiceAccount。
InitiateOAuth：GETANDREFRESH。
OAuthJWTCertType：PFXFILE.
OAuthJWTCert：Google が提供する.pfx ファイルへのパス。
OAuthJWTIssuer：サービスアカウントのE メールアドレス。このアドレスには、通常iam.gserviceaccount.com ドメインが含まれます。
OAuthJWTCertPassword（オプション）：.pfx ファイルのパスワード。Google はPFX 証明書を暗号化するため、ほとんどの場合、これを提供する必要があります。
OAuthJWTCertSubject（オプション）：複数の証明書を格納するOAuthJWTCertType を使用している場合にのみ設定。Google によって生成されたPFX 証明書には設定しないでください。
OAuthJWTSubject（オプション）：この値は、サービスアカウントがGSuite ドメインの一部で、委任を有効にする場合にのみ設定します。このプロパティの値は、データにアクセスしたいユーザーのE メールアドレスでなければなりません。

Managed Service Identity (MSI)

Azure VM 上でPostgreSQL を実行しており、マネージドID（MSI）認証情報を自動的に取得して接続したい場合は、AuthScheme を AzureMSI に設定します。

User-Managed Identities

マネージドID のトークンを取得するには、OAuthClientId プロパティを使用してマネージドID のclient_id を指定します。

VM に複数のユーザーが割り当てられたマネージドID がある場合は、OAuthClientId も指定する必要があります。

Amazon Web Services

Amazon Web Services への認証を行うには、適切な認証情報（AWS キー）を取得し、設定パラメータを設定する必要があります。

AWS キーを取得

IAM ユーザーの認証情報を取得するには：

IAM コンソールにサインインします。
ナビゲーションペインでユーザーを選択します。
ユーザーのアクセスキーを作成または管理するには、ユーザーを選択してからセキュリティ認証情報タブに移動します。

AWS ルートアカウントの資格情報を取得するには：

ルートアカウントの認証情報を使用してAWS 管理コンソールにサインインします。
アカウント名または番号を選択します。
表示されたメニューでMy Security Credentials を選択します。
ルートアカウントのアクセスキーを管理または作成するには、Continue to Security Credentials をクリックし、［Access Keys］セクションを展開します。

AWS IAM Roles

AWS 経由で認証するには、AuthScheme をAwsIAMRoles に設定します。

AWS ロールとして認証するには、次のプロパティを設定します。

AuthScheme：AwsIAMRoles。
User：aws_iam ロールを付与したAWS ホスティングPostgreSQL ユーザー。このユーザーは、rds-db:connect 権限を含むポリシーを含むロールのAWS ユーザーにマッピングする必要があります。
AWSRoleARN：認証するIAM ユーザーに付属するロールのRole ARN。これにより、本製品は指定されたロールの認証情報を取得しようと試みます。
AWSAccessKey：認証するIAM ユーザーのアクセスキー。
AWSSecretKey：認証するIAM ユーザーのシークレットキー。

多要素認証が必要な場合は、以下を指定します。

CredentialsLocation：MFA クレデンシャルが保存される設定ファイルの場所。詳しくは、接続文字列オプションのCredentials File Location のページを参照してください。
MFASerialNumber：MFA デバイスが使用されている場合は、そのシリアル番号。
MFAToken：MFA デバイスから利用できる一時トークン。

これにより、本製品は一時的な認証情報を取得するために、リクエストでMFA 認証情報を送信します。

Note： 一時的な認証情報の有効期間（デフォルトは3600秒）を制御するには、TemporaryTokenDuration プロパティを設定します。

Note：状況によっては、AWS ルートユーザーのダイレクトなセキュリティ認証情報よりも、IAM ロールを使用して認証する方が望ましい場合があります。AWS ルートユーザーのAWSAccessKey およびAWSSecretKey を指定している場合、ロールは使用できません。

EC2 インスタンスからのAWS の使用

AuthScheme をAwsEC2Roles に設定します。

EC2 インスタンスから本製品を使用していて、そのインスタンスにIAM ロールが割り当てられている場合は、認証にIAM ロールを使用できます。本製品は自動的にIAM ロールの認証情報を取得し、それらを使って認証するため、AWSAccessKey およびAWSSecretKey を指定する必要はありません。

認証にIAM ロールも使用している場合は、さらに以下を指定する必要があります。

AWSRoleARN：認証したいロールのRole ARN を指定。これにより、本製品は指定されたロールの認証情報を取得しようと試みます。
AWSExternalId（オプション）：別のAWS アカウントでロールを引き受ける場合にのみ必要です。

IMDSv2 サポート

PostgreSQL 本製品は、IMDSv2 をサポートしています。IMDSv1 とは異なり、新バージョンでは認証トークンが必須です。エンドポイントおよびレスポンスは、両バージョンで同じです。

IMDSv2 では、PostgreSQL 本製品はまずIMDSv2 メタデータトークンの取得を試み、それを使用してAWS メタデータエンドポイントを呼び出します。トークンを取得できない場合、本製品はIMDSv1 を使用します。

Kerberos

Kerberos 認証は、CData Excel Add-In for PostgreSQL が接続を試行している際にPostgreSQL サーバーで開始されます。この認証方法を有効化するには、PostgreSQL サーバーでKerberos を設定します。PostgreSQL サーバーでのKerberos 認証の設定を完了したら、本製品からKerberos 認証を行う方法についてKerberos の使用を参照してください。

接続プロパティ

最後に、Connection プロパティを参照してください。接続の確立に使用できるさまざまなオプションの説明があります。

接続の管理

PostgreSQL への認証に成功すると、インポートするデータをカスタマイズすることができます。詳しくは、接続の管理を参照してください。

Excel Add-In for PostgreSQL