翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # トラステッドコンテキストを使用して、AWS の Db2 フェデレーションデータベースのユーザーアクセスを保護し、合理化する *Amazon Web Services、Sai Parthasaradhi* ## 概要 多くの企業がレガシーメインフレームワークロードをAmazon Web Services (AWS) に移行しています。この移行には、IBM Db2 for z/OS データベースを Amazon Elastic Compute Cloud (Amazon EC2) 上の Linux、Unix、および Windows (LUW) 用の Db2 (LUW) に移行することが含まれます。オンプレミスから AWS への段階的移行中、すべてのアプリケーションとデータベースが Db2 LUW に完全に移行されるまで、ユーザーは IBM Db2 z/OS と Amazon EC2 上の Db2 LUW のデータにアクセスする必要がある場合があります。このようなリモートデータアクセスのシナリオでは、プラットフォームが異なれば使用する認証メカニズムも異なるため、ユーザー認証は難しい場合があります。 このパターンは、Db2 for z/OS をリモートデータベースとして Db2 for LUW 上にフェデレーションサーバーをセットアップする方法を網羅しています。このパターンでは、トラステッドコンテキストを使用して、リモートデータベースで再認証することなく、ユーザーの ID を Db2 LUW から Db2 z/OS に伝達します。トラステッドコンテキストについて詳しくは、「[追加情報](#secure-and-streamline-user-access-in-a-db2-federation-database-on-aws-by-using-trusted-contexts-additional)」セクションを参照してください。 ## 前提条件と制限事項 **前提条件** + アクティブな AWS アカウント + Amazon EC2 インスタンスで実行されている Db2 インスタンス + オンプレミスで実行されているリモート Db2 for z/OS データベース + [AWS Site-to-Site VPN](https://aws.amazon.com/vpn/) または [AWS Direct Connect](https://aws.amazon.com/directconnect/) を介して AWS に接続されたオンプレミスネットワーク ## アーキテクチャ **ターゲットアーキテクチャ** ![オンプレミスのメインフレームは、オンプレミスの Db2 サーバーと VPN を介して EC2 上の Db2 DB に接続します。](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/9e04f0fe-bae2-412a-93ac-83da50222017/images/0a384695-7907-4fb8-bb7e-d170dcc114af.png) ## ツール ** サービス** + 「[Amazon Elastic Compute Cloud (Amazon EC2)](https://docs.aws.amazon.com/ec2/)」は、AWS クラウドでスケーラブルなコンピューティング容量を提供します。必要な数の仮想サーバーを起動することができ、迅速にスケールアップまたはスケールダウンができます。 + [AWS Site-to-Site VPN](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html) は、AWS で起動するインスタンスと独自のリモートネットワーク間でトラフィックを渡すのに役立ちます。 **その他のツール** + [db2cli](https://www.ibm.com/docs/en/db2/11.5?topic=commands-db2cli-db2-interactive-cli) は Db2 のインタラクティブコマンドラインインターフェイス (CLI)コマンドです。 ## エピック ### AWS で実行されている Db2 LUW データベースでフェデレーションを有効にする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | DB2 LUW データベースでフェデレーションを有効にします。 | DB2 LUW でフェデレーションを有効にするには、次のコマンドを実行します。
update dbm cfg using federated YES
| DBA | | データベースを再起動します。 | データベースを再起動するには、次のコマンドを実行します。
db2stop force;
db2start;
| DBA | ### リモートデータベースをカタログ化する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | リモート Db2 z/OS サブシステムをカタログ化します。 | AWS で実行されている Db2 LUW 上のリモート Db2 z/OS データベースをカタログ化するには、以下のサンプルコマンドを使用します。
catalog TCPIP NODE tcpnode REMOTE mainframehost SERVER mainframeport
| DBA | | リモートデータベースをカタログ化します。 | リモートデータベースをカタログするには、次のコマンド例を使用します。
catalog db dbnam1 as ndbnam1 at node tcpnode
| DBA | ### リモートサーバー定義を作成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | リモート Db2 z/OS データベースのユーザー認証情報を収集します。 | 次の手順に進む前に、以下の情報を収集します。[See the AWS documentation website for more details](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/secure-and-streamline-user-access-in-a-db2-federation-database-on-aws-by-using-trusted-contexts.html) | DBA | | DRDA ラッパーを作成します。 | DRDA ラッパーを作成するには、次のコマンドを実行します。
CREATE WRAPPER DRDA;
| DBA | | サーバー定義を作成します。 | サーバー定義を作成するには、次のコマンド例を実行します。
CREATE SERVER ndbserver
TYPE DB2/ZOS VERSION 12
WRAPPER DRDA
AUTHORIZATION "dbuser1" PASSWORD "dbpasswd" OPTIONS ( DBNAME 'ndbnam1',FED_PROXY_USER 'ZPROXY' );

この定義では、`FED_PROXY_USER` が Db2 z/OS データベースへの信頼できる接続を確立するために使用するプロキシユーザーを指定します。認可ユーザー ID とパスワードは、Db2 LUW データベースにリモートサーバーオブジェクトを作成する場合にのみ必要です。これらは後のランタイムには使用されません。 | DBA | ### ユーザーマッピングの作成 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | プロキシユーザーのユーザーマッピングを作成します。 | プロキシユーザーのユーザーマッピングを作成するには、次のコマンドを実行します。
CREATE USER MAPPING FOR ZPROXY SERVER ndbserver OPTIONS (REMOTE_AUTHID 'ZPROXY', REMOTE_PASSWORD 'zproxy');
| DBA | | Db2 LUW で各ユーザーのユーザーマッピングを作成します。 | プロキシユーザーを介してリモートデータにアクセスする必要がある AWS 上の Db2 LUW データベース上のすべてのユーザーのユーザーマッピングを作成します。ユーザーマッピングを作成するには、次のコマンドを実行します。
CREATE USER MAPPING FOR PERSON1 SERVER ndbserver OPTIONS (REMOTE_AUTHID 'USERZID', USE_TRUSTED_CONTEXT 'Y');

このステートメントは、Db2 LUW (`PERSON1`) 上のユーザーがリモート Db2 z/OS データベース (`USE_TRUSTED_CONTEXT 'Y'`) への信頼できる接続を確立できることを明記しています。プロキシユーザーを介して接続が確立されると、ユーザーは Db2 z/OS ユーザー ID (`REMOTE_AUTHID 'USERZID'`) を使用してデータにアクセスできます。 | DBA | ### トラステッドコンテキストオブジェクトを作成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | トラステッドコンテキストオブジェクトを作成します。 | リモート Db2 z/OS データベースにトラステッドコンテキストオブジェクトを作成するには、以下のサンプルコマンドを使用します。
CREATE TRUSTED CONTEXT CTX_LUW_ZOS
BASED UPON CONNECTION USING SYSTEM AUTHID ZPROXY
ATTRIBUTES (
ADDRESS '10.10.10.10'
)
NO DEFAULT ROLE
ENABLE
WITH USE FOR PUBLIC WITHOUT AUTHENTICATION;

この定義では、`CTX_LUW_ZOS` はトラステッドコンテキストオブジェクトの任意の名前です。このオブジェクトには、信頼できる接続の発信元となるサーバーのプロキシユーザー ID と IP アドレスが含まれます。この例では、サーバーは AWS 上の Db2 LUW データベースです。IP アドレスの代わりにドメイン名を使用できます。この条項は、信頼できる接続でのユーザー ID の切り替えがすべてのユーザー ID で許可されていることを `WITH USE FOR PUBLIC WITHOUT AUTHENTICATION` 示しています。パスワードを入力する必要はありません。 | DBA | ## 関連リソース + [IBM Resource Access Control Facility (RACF)](https://www.ibm.com/products/resource-access-control-facility) + [IBM Db2 LUW Federation](https://www.ibm.com/docs/en/db2/11.5?topic=federation) + [Trusted contexts](https://www.ibm.com/docs/en/db2-for-zos/13?topic=contexts-trusted) ## 追加情報 **Db2 トラステッドコンテキスト** トラステッドコンテキストは、フェデレーションサーバーとリモートデータベースサーバー間の信頼関係を定義する Db2 データベースオブジェクトです。信頼できる関係を定義するために、トラステッドコンテキストは信頼属性を指定します。信頼属性には、3 つのタイプがあります。 + 最初のデータベース接続要求を行うシステム許可 ID + 接続元の IP アドレスまたはドメイン名 + データベースサーバーとデータベースクライアント間のデータ通信の暗号化設定 接続要求のすべての属性が、サーバー上で定義されているトラステッドコンテキストオブジェクトで指定されている属性と一致すると、信頼できる接続が確立されます。信頼接続には、暗黙的な接続と明示的な接続の 2 つのタイプがあります。暗黙的な信頼接続が確立されると、その信頼された接続定義の範囲外では使用できないロールがユーザーに継承されます。明示的な信頼された接続が確立されると、ユーザーは認証の有無にかかわらず、同じ物理接続に切り替えることができます。さらに、Db2 ユーザーには、信頼できる接続内でのみ使用できる権限を指定するロールを付与できます。このパターンでは、明示的な信頼できる接続を使用します。 このパターンのトラステッドコンテキスト パターンが完成すると、Db2 LUW 上の PERSON1 は、フェデレーテッドトラステッドコンテキストを使用して Db2 z/OS のリモートデータにアクセスします。PERSON1 への接続がトラステッドコンテキスト定義で指定されている IP アドレスまたはドメイン名から発信されている場合、PERSON1 への接続はプロキシユーザーを介して確立されます。接続が確立されると、PERSON1 の対応する Db2 z/OS ユーザー ID は再認証なしで切り替えられ、ユーザーはそのユーザーに設定された Db2 権限に基づいてデータまたはオブジェクトにアクセスできます。 フェデレーションされたトラステッドコンテキストの利点 + このアプローチでは、すべてのユーザーが必要とするすべての特権のスーパーセットを必要とする共通のユーザー ID やアプリケーション ID を使用する必要がなくなるため、最小特権という原則が維持されます。 + フェデレーテッドデータベースとリモートデータベースの両方でトランザクションを実行するユーザーの実際の ID は常に知られており、監査することができます。 + フェデレーションサーバーによる再認証を必要とせずに物理接続がユーザー間で再利用されるので、パフォーマンスが向上します。