セキュリティ ソリューションと標準を確認する
セキュリティに関心がおありですか? アトラシアンも関心があります。アトラシアンの取り組みと、お客様にもできることをご確認ください。
認証ポリシーについて理解する
認証ポリシーによって、組織内のユーザーと設定のセットごとに認証設定を指定できます。Atlassian 組織にアクセスするユーザーの本人確認を行います。
認証ポリシーは、以下のようになります。
デフォルト ポリシー: 管理されたアカウントからデフォルト ポリシーにメンバーを自動的に追加します。
シングル サインオン (SSO): SAML または G Suite SSO を通してアトラシアンへのログインをいつ強制するかを追跡します。
2 段階認証: ログイン時に 2 段階の認証を求めるか、メンバーに対してはそれを任意にするかを追跡します。
パスワード要件: パスワードの強さと有効期限の最低要件を追跡します。
アイドル セッション時間 – メンバーがログアウトされるまでの非アクティブ状態の継続時間を追跡します。
請求対象外ポリシー - 特定のユーザーに対して支払いを行わない場合は、請求対象外ポリシーを使用します。このポリシーでは、メンバーのセキュリティが制限されます。
メンバー: これによって、いつメンバーがポリシーに追跡されるか、別のポリシーに移動されるかを追跡しやすくなります。
複数の製品がある組織の場合、製品ではなく組織内のユーザー用の認証ポリシーを作成します。ユーザーに製品へのアクセス権を付与したい場合、製品アクセス権を付与します。
複数の認証ポリシーのための Atlassian Access
組織は、1 つのポリシーで運営できます。ユーザーのサブセットに対して複数のポリシーを適用し、組織全体にロール アウトする前に設定をテストできるため、柔軟性があります。
複数の認証ポリシーを作成するには、Atlassian Access サブスクリプションが必要です。Atlassian Access の詳細をご確認ください。
認証ポリシーのユース ケース
組織を管理するため、複数のポリシーを作成して、複数のユーザー セットのセキュリティに対応します。また、ユーザーのサブセットの設定をテストします。小さいユーザーのセットで設定をテストする場合、組織全体には機能しない可能性があるポリシーのロール アウトは避けます。
組織に対して最大 20 のポリシーを作成できます。
次に示すのは、組織に対する認証ポリシーの使用方法の例です。
複数のユーザーのサブセットに対する複数のポリシー
ユーザーによって、認証のニーズは異なります。そのニーズに対応するため、組織内のユーザーのサブセットそれぞれに対してポリシーを作成います。これは、複数のポリシーを作成することを意味します。
たとえば、以下の手順が可能です。
正社員、請負業者、C-Suite、パートナーなど、特定の一連のユーザーにさまざまなポリシーを作成します。
ボット アカウント用の認証設定をカスタマイズします
認証設定のテスト
リスクを軽減して、公開前にユーザーのサブセットの設定をテストできる必要があります。
たとえば、以下の手順が可能です。
ユーザーのより小さいサブセットで 2 段階認証をテストして、組織間でロールアウトする前に正しく設定されていることを確認します。
管理テスト アカウントごとに異なるポリシーを設定することで、SSO をテストします。それによって、ログインしてポリシーのトラブルシューティングを実施できます。
デフォルト認証ポリシーとは何ですか?
管理対象アカウントは、認証ポリシーのためのユーザーのプールがあります。ポリシーのメンバーとなるユーザーを割り当てます。組織には、まずデフォルト認証ポリシーが適用されます。デフォルト ポリシーには、メンバーのログイン設定が含まれます。新しい管理アカウントをプロビジョニングする場合、デフォルト ポリシーにメンバーとして追加します。
他のポリシーをデフォルト ポリシーにするには:
admin.atlassian.com に移動します。複数の組織がある場合は、組織を選択します。
[セキュリティ] > [認証ポリシー] の順に選択します。
デフォルトにするポリシーの [編集] を選択します。
[Make default policy (デフォルト ポリシーを作成する)] を選択します。
既定のポリシーは削除できません。
1. 既定にする他のポリシーを選択します。
2. ポリシーを削除します (既定のポリシーではなくなりました)。
ポリシーを削除するには:
admin.atlassian.com に移動します。複数の組織がある場合は、組織を選択します。
[セキュリティ] > [認証ポリシー] の順に選択します。
削除するポリシーの [編集] を選択します。
[Delete policy (ポリシーを削除する)] を選択します。
What is a non-billable policy?
The ability to see a default policy as non-billable will be available in August of 2022. Until August of 2022, a default policy can’t be a non-billable policy. A default policy is always billable.
When users are either manually invited or sign themselves up, you can decide whether to include them in your Atlassian Access subscription.
With an Atlassian Access subscription, you can create a non-billable policy when you don’t want to pay for certain users. We won't bill you for users in a non-billable policy. You can only have one (1) non-billable policy. You can only create a non-billable policy in a local directory. Learn more about directories
When you edit authentication policies and make a policy non-billable, you won't be able to:
シングル サインオンを強制
2 段階認証を要求
ID プロバイダー (Okta、Azure AD、G Suite など) からポリシーに同期するユーザーを追加
You can't add the users you sync from your identity provider (e.g., Okta, Azure AD, Google Workspace) to a non-billable policy.
If you sync users that are part of a non-billable policy, we move them to a different policy and directory. You can find these users in the default policy of your identity provider directory.
You can easily update your policy to include all security settings. Once you do, the users in the policy may count towards your Atlassian Access bill.
To make a policy non-billable:
admin.atlassian.com で [認証ポリシー] に移動します。
Select Edit for the policy you want to make non-billable.
Select Make policy non-billable.
To update a non-billable policy to all security settings:
admin.atlassian.com で [認証ポリシー] に移動します。
Select Edit for the non-billable policy.
Select Add all security settings to policy.
Update policy.
この内容はお役に立ちましたか?