認証ポリシー

robotsnoindex
robotsnoindex


認証ポリシーによって、組織内のユーザーと設定のセットごとに認証設定を指定できます。Atlassian 組織にアクセスするユーザーの本人確認を行います。

認証ポリシーは、以下のようになります。


  1. デフォルト ポリシー: 管理されたアカウントからデフォルト ポリシーにメンバーを自動的に追加します。

  2. シングル サインオン (SSO): SAML または G Suite SSO を通してアトラシアンへのログインをいつ強制するかを追跡します。

  3. 2 段階認証: ログイン時に 2 段階の認証を求めるか、メンバーに対してはそれを任意にするかを追跡します。

  4. パスワード要件: パスワードの強さと有効期限の最低要件を追跡します。

  5. アイドル セッション時間: メンバーが強制的にログアウトされるまでの非アクティブ状態の継続時間を追跡します。

  6. メンバー: これによって、いつメンバーがポリシーに追跡されるか、別のポリシーに移動されるかを追跡しやすくなります。

複数の製品がある組織の場合、製品ではなく組織内のユーザー用の認証ポリシーを作成します。ユーザーに製品へのアクセス権を付与したい場合、製品アクセス権を付与します。

設定の編集方法またはメンバーの追加方法に関する詳細をご確認ください。

複数の認証ポリシーのための Atlassian Access

組織は、1 つのポリシーで運営できます。ユーザーのサブセットに対して複数のポリシーを適用し、組織全体にロール アウトする前に設定をテストできるため、柔軟性があります。

複数の認証ポリシーを作成するには、Atlassian Access サブスクリプションが必要です。Atlassian Access の詳細をご確認ください。

認証ポリシーのユース ケース

組織を管理するため、複数のポリシーを作成して、複数のユーザー セットのセキュリティに対応します。また、ユーザーのサブセットの設定をテストします。小さいユーザーのセットで設定をテストする場合、組織全体には機能しない可能性があるポリシーのロール アウトは避けます。

組織に対して最大 20 個のポリシーを作成できます。

以下に示すのは、組織に対する認証ポリシーの使用方法の例です。

複数のユーザーのサブセットに対する複数のポリシー

ユーザーによって、認証のニーズは異なります。そのニーズに対応するため、組織内のユーザーのサブセットそれぞれに対してポリシーを作成います。これは、複数のポリシーを作成することを意味します。

たとえば、以下の手順が可能です。

  • 正社員、請負業者、C-Suite、パートナーなど、特定のユーザーのセットに対して複数のポリシーを作成します

  • ボット アカウント用の認証設定をカスタマイズします

認証設定のテスト

リスクを軽減し、ロール アウトする前にユーザーのサブセットの設定をテストできる必要があります。

たとえば、以下の手順が可能です。

  • ユーザーのより小さいサブセットで 2 段階認証をテストして、組織間でロールアウトする前に正しく設定されていることを確認します。

  • 管理テスト アカウントごとに異なるポリシーを設定することで、SSO をテストします。それによって、ログインしてポリシーのトラブルシューティングを実施できます。

デフォルト認証ポリシーとは何ですか?

管理対象アカウントは、認証ポリシーのためのユーザーのプールがあります。ポリシーのメンバーとなるユーザーを割り当てます。組織には、まずデフォルト認証ポリシーが適用されます。デフォルト ポリシーには、メンバーのログイン設定が含まれます。新しい管理アカウントを提供する場合、デフォルト ポリシーにメンバーとして追加します。

他のポリシーをデフォルト ポリシーにするには:

  1. admin.atlassian.com で [認証ポリシー] に移動します。

  2. デフォルトにするポリシーの [編集] を選択します。

  3. [Make default policy (デフォルト ポリシーを作成する)] を選択します。

デフォルトのポリシーは削除できません
1. デフォルトにする他のポリシーを選択します。
2. (デフォルト ポリシーではなくなった) ポリシーを削除します。

ポリシーを削除するには:

  1. admin.atlassian.com で [認証ポリシー] に移動します。

  2. 削除するポリシーの [編集] を選択します。

  3. [Delete policy (ポリシーを削除する)] を選択します。

請求対象外ポリシーとは何ですか?

Atlassian Access へのサブスクリプションでは、特定のユーザーに関する料金を支払わない際に請求対象外ポリシーを使用できます。請求対象外ポリシーのメンバーについては請求しません。

作成できる請求対象外ポリシーは 1 つだけです。Atlassian Access へのサブスクリプションでは、作成できる請求対象外ポリシーは 1 つだけです。請求対象外ポリシーでは、メンバーのセキュリティは制限されます。認証ポリシーを編集してポリシーを請求対象外にする際は、次を行えなくなります。

  • シングル サインオンを強制

  • 2 段階認証を要求

  • ID プロバイダー (Okta、Azure AD、G Suite など) からポリシーに同期するユーザーを追加

同期されたユーザーは請求対象外ポリシーには追加できません。同期されたユーザーを請求対象外ポリシーに追加すると、そのユーザーはデフォルト ポリシーに移動されます。これをポリシーで確認するには、時間がかかる場合があります。

請求対象外ポリシーを作成するには、次を実行します。

  1. admin.atlassian.com で [認証ポリシー] に移動します。

  2. 請求不可にするポリシーの [編集] を選択します。ポリシーは既定のポリシーにできません。

  3. [ポリシーを請求対象外にする] を選択して、ポリシーをアップデートします。

ポリシー メンバーを追加して移動する方法を説明します

ポリシーを簡単に更新してすべてのセキュリティ設定に戻せます。実行すると、そのメンバーは Atlassian Access の請求対象になります。

デフォルト ポリシーは請求対象外ポリシーにはできません。デフォルト ポリシーは常に請求対象です。特定のメンバーについては支払わない場合は、別のポリシーを請求対象外にしてそのポリシーにメンバーを追加します。




最終更新日 2021 年 6 月 3 日

この内容はお役に立ちましたか?

はい
いいえ
この記事についてのフィードバックを送信する
Powered by Confluence and Scroll Viewport.