MongoDB Atlas は、堅牢なセキュリティを確保するために多様な認証方法をサポートしています。Atlas では、Atlas UI、Atlas データベース、および Atlas 管理API にアクセスするために、すべてのユーザーが認証を行う必要があります。
注意
この文脈では、「ユーザー」は人間またはアプリケーションを指すことができます。人間のユーザーを「ワークフォース・アイデンティティ」、アプリケーションを「ワークロード・アイデンティティ」と呼びます。
使用する認証タイプは、次の 2 つの要素によって決まります。
アイデンティティの種類（人間またはマシン）
アイデンティティがアクセスする必要のあるリソース。リソースは、Atlas UI、Atlas データベース、Atlas API のいずれかです。
Atlas UI 認証
Workforce ユーザー
IP アクセス制限を使用して、次の操作を行います。
フェデレーティッド認証を SAML 2.0 IdP（Okta、Microsoft Entra ID、Ping Identity など）と共に使用します。そして
Atlas 認証情報を多要素認証（MFA）と共に使用します。ハードウェア キーや生体認証など、利用可能な中で最も安全な形式の MFA を常に使用する必要があります。
Workload ユーザー
これは、Workforce ユーザーにのみ適用されます。
Atlas のデータベース認証
Workforce ユーザー
Workforce Identity Federation を使用します。
開発環境やテスト環境では、SCRAM も使用できます。ジャストインタイム データベース アクセスで、一時的なデータベースユーザーを作成することを検討してください。
Workload ユーザー
次のいずれかを使用します。
Atlas API 認証
注意
これは、Workforce ユーザーと Workload ユーザーの両方に適用されます。
認証タイプ
次のセクションでは、Atlas UI、Atlas データベース、または Atlas 管理API にアクセスする際に使用する認証方法について詳しく説明します。
フェデレーティッド認証
フェデレーティッド認証を使用すると、中央のIdPを通じて、複数のシステムやアプリケーションで Atlas UI へのすべての認証を管理できるため、ユーザーマネジメントの複雑さが軽減されます。フェデレーティッド認証を使用すると、パスワードの複雑さ、認証情報のローテーション、MFA などのセキュリティポリシーを IdP のツール内で強制できます。
Atlas UI では、Okta、Microsoft Entra ID、Ping Identity などの SAML 互換の IdP を使用できます。
Workforce IdP
Workforce Identity Federation を使用すると、IdP を通じて、Atlas データベースへのすべての認証を管理できます。詳細については、「OIDC を使用した Workforce Identity Federation の設定」を参照してください。
Workload Identity Federation
Workload Identity Federation を使用すると、Azure や Google Cloud などのクラウド環境で実行されているアプリケーションが、データベースユーザーの認証情報を個別に管理することなく Atlas で認証できます。Workload Identity Federation を使用すると、Azureマネージド ID、Google サービスアカウント、または任意の OAuth 2.0 準拠のサービスを使用して、Atlas データベースユーザーを管理できます。これらの認証メカニズムは、Atlas データベースへのパスワードレス アクセスを可能にすることで、管理を簡素化し、セキュリティを強化します。
AWS IAM ロール認証
また、AWS IAM ロールを通じて認証することもできます。詳細については、「AWS IAM 認証」を参照してください。
詳細については、「OAuth 2.0 を使用したWorkload Identity Federationの設定」と「フェデレーティッド認証の構成」を参照してください。
多要素認証
Atlas コントロール プレーンにアクセスするすべての人間ユーザーには、セキュリティを強化するために MFA を必須としています。Atlas は、セカンダリ ID として以下の MFA 方式をサポートしています。
セキュリティキー
生体認証
OTP 認証子
Okta Verify を使用したプッシュ通知
メールアドレス
注意
フェデレーティッド認証を使用している場合は、IdP で MFA を構成および管理します。Atlas の認証情報を使用している場合、MFA は Atlas 内で構成および管理されます。Atlas の認証情報を使用する場合は、MFA が必要です。
詳細は、「多要素認証オプションを管理する」を参照してください。
X.509 クライアント証明書
X.509 証明書は相互 TLS のセキュリティを提供するため、ステージングおよび本番環境に適しています。また、X.509 で使用するために独自の認証局を持ち込むことができます。X.509 の欠点は、証明書とそのセキュリティをアプリケーション側で管理しなければならないことです。一方、Workload Identity Federation を使用すると、パスワードレスのアクセスが可能になり、アプリケーションのセキュリティが容易になります。
詳細については、「X.509」を参照してください。
SCRAM パスワード認証
Atlas クラスターはユーザー認証に SCRAM パスワード認証をサポートしていますが、SCRAM は開発環境とテスト環境でのみ使用することをお勧めします。
X.509 または SCRAM認証を活用する場合は、複雑なデータベース認証情報を生成および保存するために、HashiCorp Vault やAmazon Web Services Secrets Manager などのサードパーティのシークレット マネージャーを使用することをお勧めします。
詳細については、「SCRAM」を参照してください。
サービス アカウント
サービス アカウントは業界標準の OAuth2.0 を使用して、Atlas Administration API を介して Atlas へのセキュアな認証を行います。可能な限り API キーの代わりにサービスアカウントの使用を推奨します。これは、短期間のアクセストークンと必須の認証情報ローテーションにより、セキュリティが強化されるためです。
サービス アカウントのプログラムによるアクセスは、Atlas UI、Atlas CLI、Atlas 管理API、Terraform を使用して管理できます。
API キー
サービス アカウントは、推奨される認証方法です。Atlas は、プログラムによるアクセスを管理するための API キーに基づく認証のレガシーサポートを提供します。API キー ベースの認証は、リクエストを保護するために HTTP ダイジェスト認証を使用します。
セキュリティをさらに強化し、不正アクセスのリスクを最小限に抑えるためには:
ベストプラクティスに従って、 APIキーを定期的にローテーションします。HashiCorp Vault（例:）を使用してこれらのキーをローテーションする方法については、HashiCorp のドキュメントを参照してください。
API キーに対する IP アクセスリストを使用します。詳細については、「Atlas Administration API の IP アクセス リストを要求する」を参照してください。
詳細については、「Atlas Administration API 認証」を参照してください。
秘密マネジメント
複雑なデータベース認証情報を生成して保存するには、HashiCorp Vault や Amazon Web Services Secrets Manager などのサードパーティのシークレット マネージャーを使用することをお勧めします。シークレット マネージャーは、Atlas データベースの構成されたロールに基づいてデータベース認証情報を動的に生成できます。
詳細については、ブログの「HashiCorp Vault で MongoDB Atlas データベースのシークレットを管理する」を参照してください。
配置
認証に関連する配置の推奨事項を学ぶには、「Atlas 組織、プロジェクト、およびクラスターに関するガイダンス」を参照してください。
追加のセキュリティ対策
セキュリティをさらに強化し、不正アクセスのリスクを最小限に抑えるために、次の追加のセキュリティ対策を検討してください。
有効期限が切れる前にサービス アカウントのシークレットをローテーションします。
サービス アカウントにIP アクセス リストを使用します。
サービス アカウントの目的に必要な最小権限の Atlas ロール を割り当て、最小権限の原則を遵守します。
詳細については、「サービス アカウントの概要」を参照してください。