AWS Managed Microsoft AD の主要なコンセプト - AWS Directory Service

AWS Managed Microsoft AD の主要なコンセプト

以下の主要なコンセプトを理解すると、AWS Managed Microsoft AD をさらに活用できます。

アクティブディレクトリのスキーマ

スキーマとは、分散ディレクトリの一部をなしている属性とクラスの定義のことであり、データベースにおけるフィールドとテーブルに類似しています。スキーマには、データベースに追加または含めることができるデータの型や形式を決定する、一連のルールが含まれています。User クラスは、データベースに保存される クラス の一例です。例として、User クラスの属性には、ユーザーの姓、名、電話番号などを含めることができます。

スキーマの要素

属性、クラス、オブジェクトは、スキーマのオブジェクト定義を作成するために使用される基本要素です。AWS Managed Microsoft AD スキーマを拡張するプロセスを開始する前に知っておく必要がある、スキーマ要素の詳細を以下に示します。

属性

各スキーマ属性は、データベース内のフィールドと類似しており、それ自体の特性を定義するためのプロパティをいくつか含んでいます。例えば、LDAPDisplayName は属性を読み書きするために LDAP クライアントで使用されるプロパティです。LDAPDisplayName プロパティは、すべての属性とクラスにおいて一意である必要があります。属性の特性に関する詳細な一覧については、MSDN ウェブサイトの「Characteristics of Attributes」(属性の特性) を参照してください。新しい属性の作成方法に関する詳細なガイダンスについては、MSDN ウェブサイトの「Defining a New Attribute」(新しい属性の定義) を参照してください。

クラス

クラスは、データベースにおけるテーブルに相当するもので、複数のプロパティを定義することができます。例えば、objectClassCategory は、クラスのカテゴリを定義します。クラスの特性の詳細なリストについては、MSDN ウェブサイトの「Characteristics of Object Classes」(オブジェクトクラスの特性) を参照してください。新しいクラスの作成方法に関する詳細については、MSDN ウェブサイトの「Defining a New Class」(新しいクラスの定義) を参照してください。

オブジェクト識別子 (OID)

各クラスおよび属性には、オブジェクトの全体で一意である OID を含める必要があります。ソフトウェアベンダーは、独自の OID を取得して、一意性を確保する必要があります。一意性を確保することで、複数のアプリケーションにおいて同一の属性が異なる目的で使用された場合の競合が回避されます。一意性を確保するには、ISO Name Registration Authority (ISO 名前登録機関) からルート OID を取得します。あるいは、Microsoft から基本 OID を取得することも可能です。OID および OID の取得方法に関する詳細については、MSDN ウェブサイトの「Object Identifiers」(オブジェクト識別子) を参照してください。

スキーマとリンクした属性

一部の属性は、2 つのクラス間で、前後の双方向でリンクされています。この最も適切な例としてはグループがあります。グループを調べると、そのグループのメンバーを確認でき、ユーザーを見た場合は、それが所属するグループを確認できます。ユーザーをグループに追加すると、Active Directory によってグループに対する前方リンクが作成されます。次に Active Directory は、グループからユーザーへの後方リンクを追加します。リンクされる属性が作成される際には、一意のリンク ID も生成される必要があります。詳細については、MSDN ウェブサイトの「Linked Attributes」(リンク属性) を参照してください。

AWS Managed Microsoft AD のパッチ適用とメンテナンス

AWS Directory Service for Microsoft Active Directory (別名: AWS DS for AWS Managed Microsoft AD) とは、実際には Microsoft Active Directory のドメインサービス (AD DS) であり、マネージド型サービスとして提供されています。システムはドメインコントローラー (DC) 用に Microsoft Windows Server 2019 を使用し、AWS は サービス管理の目的で DC にソフトウェアを追加します。また、AWS は DC を更新 (パッチ適用) して新しい機能の追加を行うと同時に、Microsoft Windows Server ソフトウェアを最新の状態に保ちます。パッチ適用プロセス中も、ディレクトリは引き続き使用可能な状態を維持します。

可用性の確保

デフォルトでは、各ディレクトリは 2 つの DC で構成され、それぞれが異なるアベイラビリティーゾーンにインストールされています。お客様の選択により、DC を追加して可用性をさらに高めることができます。高可用性と耐障害性を必要とする重要な環境では、DC を追加で導入することをお勧めします。AWS は DC に対しパッチを順番に適用します。がパッチ適用処理を実行している DC AWS は利用できなくなります。1 つ以上の DC が一時的に使用停止状態になった場合、AWS は、ディレクトリに少なくとも 2 つの運用可能な DC が検出されるまでパッチ適用を延期します。これにより、パッチ処理中であっても、ユーザーには運用可能な他の DC を提供することができます。通常、パッチには DC ごとに 30〜45 分を要しますが、この時間は変動する可能性があります。パッチを含む何らかの理由で 1 つ以上の DC が利用できない場合に、アプリケーションが動作中の DC にアクセスできるようにするには、静的な DC アドレスではなく Windows DC ロケーターサービスを使用するように、そのアプリケーションを設定します。

パッチ適用のスケジュールを理解する

お使いの DC の Microsoft Windows Server ソフトウェアを最新の状態に保つために、AWS はMicrosoft アップデートを利用しています。Microsoft による、Windows Server 用の月次ロールアップパッチが利用可能になったため、AWS は、すべての顧客 DC に対するロールアップを 3 週間以内にテストならびに適用するよう、最善を尽くしています。さらに、DC への適用性と緊急性に基づいて、AWS は、Microsoft が毎月のロールアップ外でリリースする更新のレビューを行います。Microsoft によりクリティカルまたは重要と評価され、DC に関連性のあるセキュリティパッチについて、AWS は、5 日間以内にそのパッチをテストしデプロイするための最大限の努力を払います。

グループ管理サービスアカウント

Microsoft は、グループ管理サービスアカウント (gMSA) と呼ばれる (サービス用の) アカウントを、管理者が管理するための新たな手法を Windows Server 2012 に導入しました。gMSA を使用することで、サービス管理者はサービスインスタンス間のパスワードを手動で同期させる必要がなくなります。代わりに、管理者は Active Directory 内に単一の gMSA を作成し、この gMSA を複数のサービスインスタンスで使用するように設定します。

AWS Managed Microsoft AD のユーザーに対し、gMSA を作成するための許可を付与するには、そのユーザーのアカウントをセキュリティグループ (AWS Delegated Managed Service Account Administrators) のメンバーに追加する必要があります。管理者アカウントは、デフォルトでこのグループのメンバーになっています。gMSA の詳細については、Microsoft TechNet ウェブサイトの「Group Managed Service Accounts Overview」(グループ管理サービスアカウントの概要) を参照してください。

AWS セキュリティブログの関連記事

Kerberos の制約付き委任

Kerberos の制約付き委任は、Windows Server の機能の 1 つです。この機能を使用するサービス管理者は、アプリケーションサービスがユーザーの代わりに行う処理の範囲を制限することで、アプリケーションの信頼の境界を指定し適用できます。これは、バックエンドサービスに委任できるフロントエンドサービスアカウントを指定する際の役に立ちます。Kerberos の制約付き委任は、任意あるいはすべてのサービスに、gMSA が Active Directory ユーザーに代わり接続することを防止し、承認されていない開発者による不正使用の可能性を排除します。

例えば、ユーザー jsmith が HR アプリケーションにログインする場合を考えます。この時、SQL Server で jsmith のデータベースへのアクセス許可を適用する必要があります。ただし、SQL Server のデフォルトでは、データベース接続を開く際に jsmith で設定済みのアクセス許可を使用せず、(hr-app-service のアクセス許可を適用する) サービスアカウントの認証情報を使用します。HR 給与アプリケーションが SQL Server データベースにアクセスするために、jsmith の認証情報を使用できるように設定する必要があります。そのためには、AWS 内にある AWS Managed Microsoft AD ディレクトリの hr-app-service サービスアカウントに対して Kerberos の制約付き委任を有効にします。jsmith がログオンすると、このユーザー がネットワークの他のサービスへのアクセスを試みた場合に Windows が自動的に使用する Kerberos チケットが、Active Directory から提供されます。Kerberos の委任により、hr-app-service アカウントは jsmith の Kerberos チケットを再利用してデータベースにアクセスできます。つまり、jsmith に固有のアクセス許可を適用してデータベース接続を開くことが可能です。

Kerberos の制約付き委任を設定するアクセス許可を、AWS Managed Microsoft AD のユーザーに付与するには、それらのユーザーのアカウントをセキュリティグループ (AWS Delegated Kerberos Delegation Administrators) のメンバーとして追加する必要があります。管理者アカウントは、デフォルトでこのグループのメンバーになっています。Kerberos の制約付き委任の詳細については、Microsoft TechNet ウェブサイトの「Kerberos Constrained Delegation Overview」(Kerberos の制約付き委任の概要) を参照してください。

リソースベースの制約付き委任が、Windows Server 2012 に導入されました。これを使用することで、バックエンドサービス管理者は、サービスのために制約付き委任を設定できます。