認証ポリシーについて理解する
これで、認証ポリシー、ローカル、ID プロバイダーの各ディレクトリが表示されます。ID プロバイダーを組織に接続すると、既定の認証ポリシーがディレクトリごとに作成されます。
認証ポリシーによって、組織内のユーザーと設定のセットごとに認証設定を指定できます。Atlassian 組織にアクセスするユーザーの本人確認を行います。
認証ポリシーは、以下のようになります。
既定のポリシー - 新しいメンバーを、ローカルまたは ID プロバイダー ディレクトリにある既定のポリシーに自動で追加します。
請求対象外 - 特定のユーザーに対して支払わない場合は、請求対象外ポリシーを作成します。ローカル ディレクトリでは、請求対象外ポリシーは既定のポリシーとしてのみ設定できます。
ローカル ディレクトリ - ID プロバイダーで管理していないメンバーが含まれます。これらのユーザーを招待するか、ユーザー自身がサイン アップします。
2 段階認証 - ログイン時に 2 段階の認証を求めるか、メンバーに対してはそれを任意にします。
サードパーティ ログイン – サードパーティ アカウントからのログインを許可またはブロックします。
パスワード要件: パスワードの強さと有効期限の最低要件を追跡します。
アイドル セッション時間 – メンバーがログアウトされるまでの非アクティブ状態の継続時間を追跡します。
Mobile session expiration - Choose when a mobile app session expires for members of an authentication policy.
User API tokens - Control whether members create new or use existing tokens to authenticate.
API token expiration - Control when a user API token expires.
メンバー - ポリシーのメンバー数を表示します。メンバーを、あるポリシーから別のポリシーに追加または移動します。
SSO (シングル サインオン) - SAML または Google Workspace SSO を介した Atlassian へのログインをいつ強制するタイミングを追跡します。SSO は、ID プロバイダー ディレクトリでのみ強制できます。
Identity provider directory - Contains members you sync or authenticate through your identity provider. You can add and move members between authentication policies.
More about Authentication policies in this video
複数の製品がある組織の場合、製品ではなく組織内のユーザー用の認証ポリシーを作成します。ユーザーに製品へのアクセス権を付与したい場合、製品アクセス権を付与します。
How to edit settings or add members
アトラシアン ガバメント クラウドの認証ポリシー
認証ポリシーによって、顧客の責任要件である管理対象アカウントの SAML シングル サインオンを設定できます。アトラシアン ガバメント環境では、認証ポリシーは上の図のポリシー 2 のようになります。
認証ポリシーでは、2 段階認証、サードパーティ ログイン、パスワードの各要件の設定を確認できます。ただし、SAML シングル サインオンを適用する際には、認証ポリシーからこれらのオプションを設定できません。また、ID プロバイダーからすべてのメンバーを管理する必要がある場合は、ローカル ディレクトリを利用できません。
A non-billable policy isn't available in Atlassian Government environments. This is because the Atlassian Guard subscription is not available in Atlassian Government.
複数の認証ポリシー
組織は、1 つのポリシーで運営できます。ユーザーのサブセットに対して複数のポリシーを適用し、組織全体にロール アウトする前に設定をテストできるため、柔軟性があります。
組織で複数の認証ポリシーを作成するには、Atlassian Guard Standard サブスクリプションを利用しているか、アトラシアン ガバメント環境にある必要があります。
認証ポリシーのユース ケース
組織を管理するため、複数のポリシーを作成して、複数のユーザー セットのセキュリティに対応します。また、ユーザーのサブセットの設定をテストします。小さいユーザーのセットで設定をテストする場合、組織全体には機能しない可能性があるポリシーのロール アウトは避けます。
組織に対して最大 20 のポリシーを作成できます。
次に示すのは、組織に対する認証ポリシーの使用方法の例です。
複数のユーザーのサブセットに対する複数のポリシー
ユーザーによって、認証のニーズは異なります。そのニーズに対応するため、組織内のユーザーのサブセットそれぞれに対してポリシーを作成います。これは、複数のポリシーを作成することを意味します。
たとえば、以下の手順が可能です。
Create different policies for specific sets of users such as full-time employees, contractors, the C-Suite or partners
ボット アカウント用の認証設定をカスタマイズします
請求対象外ポリシーを作成して Atlassian Guard Standard サブスクリプションのコストを管理する
認証設定のテスト
リスクを軽減して、公開前にユーザーのサブセットの設定をテストできる必要があります。
たとえば、以下の手順が可能です。
ユーザーのより小さいサブセットで 2 段階認証をテストして、組織間でロールアウトする前に正しく設定されていることを確認します。
管理テスト アカウントごとに異なるポリシーを設定することで、SSO をテストします。それによって、ログインしてポリシーのトラブルシューティングを実施できます。
この内容はお役に立ちましたか?