MongoDB Atlas は、堅牢なセキュリティを確保するために多様な認証方法をサポートしています。Atlas では、Atlas UI、Atlas データベース、および Atlas 管理API にアクセスするために、すべてのユーザーが認証を行う必要があります。
注意
MongoDB Atlas共有責任モデルは、安全で回復力のあるデータ環境を維持するためのMongoDBとそのカスタマーの補完的な役割を定義します。このフレームワークの下、 MongoDB は基礎のプラットフォームのセキュリティと運用上の整合性を管理しますが、カスタマーは特定の配置の構成、管理、データ ポリシーに責任を負います。所有者セキュリティと運用上の優れ性の詳細な内訳については、 共有責任モデル を参照してください。
注意
この文脈では、「ユーザー」は人間またはアプリケーションを指すことができます。人間のユーザーを「ワークフォース・アイデンティティ」、アプリケーションを「ワークロード・アイデンティティ」と呼びます。
使用する認証タイプは、次の 2 つの要素によって決まります。
アイデンティティの種類（人間またはマシン）
アイデンティティがアクセスする必要のあるリソース。リソースは、Atlas UI、Atlas データベース、Atlas API のいずれかです。
Atlas UI 認証
Workforce ユーザー
IP アクセス制限を使用して、次の操作を行います。
Okta、 Microsoft Entra ID 、Ping Identity などの SAML2.0 IdPでフェデレーティッド認証を使用し、
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 IdP を使用すると、 IdPを介して Atlasデータベースへのすべての認証を管理できます。詳細については、 oidc-認証-ワークフォース を参照してください。
Workload Identity Federation
Workload Identity Federation を使用すると、AzureやGoogle Cloud Platformなどのクラウド環境で実行中アプリケーションが Atlas で認証されるため、データベースユーザーの認証情報を個別に管理する必要がなくなります。Workload Identity Federation を使用すると、Azure Managed Identity、Google サービス アカウント、または OAuth 2.0 準拠のサービスを使用して Atlasデータベースユーザーを管理できます。これらの認証メカニズムにより、Atlas データベースへのスワードレスアクセスが可能になることで、管理が簡素化され、セキュリティが強化されます。
AWS IAM ロール認証
AWS IAM ロール を介して認証することもできます。詳しくは、「 set-up-pwdless-auth 」を参照してください。
詳しくは、「 oidc-認証ワークロード 」および「 atlas-フェデレーティッド認証 」を参照してください。
多要素認証
Atlas コントロール プレーンにアクセスするすべての人間ユーザーは、セキュリティを強化するために MFA が 必要 です。Atlas はセカンダリ識別として次の 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 アクセス リストを要求する」を参照してください。
詳細については、「 api 認証 」を参照してください。
秘密マネジメント
複雑なデータベース認証情報を生成して保存するには、HashiCorp Vault や Amazon Web Services Secrets Manager などのサードパーティのシークレット マネージャーを使用することをお勧めします。シークレット マネージャーは、Atlas データベースの構成されたロールに基づいてデータベース認証情報を動的に生成できます。
詳細については、ブログの「HashiCorp Vault で MongoDB Atlas データベースのシークレットを管理する」を参照してください。
配置
認証に関連する配置の推奨事項を学ぶには、「Atlas 組織、プロジェクト、およびクラスターに関するガイダンス」を参照してください。
追加のセキュリティ対策
セキュリティをさらに強化し、不正アクセスのリスクを最小限に抑えるために、次の追加のセキュリティ対策を検討してください。
有効期限が切れる前にサービス アカウントのシークレットをローテーションします。
サービス アカウントにIP アクセス リストを使用します。
サービス アカウントの目的に必要な最小権限の Atlas ロール を割り当て、最小権限の原則を遵守します。
詳細については、「サービス アカウントの概要」を参照してください。