Atlassian Guard を開始する

はじめに

組織の可視性を高め、ユーザーのアクセスを効果的に管理するために、この 3 つのステップから企業の保護を始めましょう。

アトラシアンの組織とは

「組織」は、管理者が企業のメールアドレスを使うすべての Atlassian アカウントの表示と制御を行う管理レイヤーです。企業が利用するアトラシアンのクラウド階層の最上位に位置し、ここですべてのユーザーとコンテンツを一元管理できます。すべてのアトラシアンのサイトと製品が組織に一覧表示されるため、企業が利用するアトラシアンのクラウドの状況をすべて把握できます。組織には admin.atlassian.com からアクセスします。

ドメイン検証とは

ドメイン検証とは、企業のドメインを利用するすべての Atlassian アカウントの一元管理を組織管理者が始めるためのプロセスです。自社ドメインの DNS や HTTPS 設定を編集できる管理者は、Atlassian Guard を使って自社のドメインを検証できます。

ドメイン検証の流れ

たとえば、あなたの会社が Acme Inc. という名前で、「acme.com」と「acme.co.uk」というドメインを所有しているとします。

管理者は組織を設定した後、組織ビューの [Directory (ディレクトリ)] > [Domains (ドメイン)] ページからこれらのドメインの所有権を検証します。ドメインの Web サイトのルートフォルダーに HTML ファイルをアップロードするか、TXT レコードを自社のドメインネームシステム (DNS) にコピーします。

いずれかのステップが完了したら、「Verify（検証）」をクリックします。「jack@acme.com」や「jill@acme.co.uk」など、これらのドメインのメール・アドレスを使ってアカウントを設定したアトラシアンのクラウド・ユーザーを組織の一部として管理できるようになります。

ドメインを検証すると、現在は管理していないサイトと製品の Atlassian アカウントも管理することになります。たとえば、Atlassian クラウド製品に登録したものの、まだ管理下に置かれていないチームや従業員が企業に存在するとします。ドメインを検証する前に、社内で Atlassian クラウド製品を使っている他のサイト管理者やチームに通知して、今後の変更を知らせておくことをお勧めします。

組織の管理者がドメインを検証したら、そのドメインに属しているメール アドレスのある Atlassian ユーザーのプロファイル設定に、組織によってアカウントが管理されるようになったことを知らせるメッセージが表示されます。

組織の管理対象アカウントページにアクセスすると各アカウントのユーザー情報を編集できます。セキュリティポリシーを適用して Atlassian Guard をサブスクライブする場合、管理者が設定したポリシーが管理対象アカウントのユーザーに適用されます。

SAML SSO とは

SAML シングル・サインオン（SSO）では、企業の既存の ID プロバイダーを使って Atlassian クラウド製品を認証できます。つまり、ユーザー名とパスワードだけではなくより安全な認証方法を使いながら、同じ認証情報で複数のツールにアクセスできるのです。

SAML SSO を使う理由

SAML SSO では、従業員と顧客は、使用するツールによりシンプルで簡単な方法でアクセスできます。管理者は ID 関連のセキュリティ制御を大規模に強化して、巨大なユーザー グループのセキュリティ確保というタスクをもっとシンプルにできます。

仕組み

現在利用している ID プロバイダーと Atlassian Guard を統合して、アトラシアンのクラウド製品にアクセスする従業員と顧客の認証プロセスをシンプルかつシームレスなものにします。

ユーザーのプロビジョニングと解除とは

ユーザーをプロビジョニングまたは解除することによって、外部ディレクトリで設定したルールでアトラシアンのクラウド製品へのアクセスを定義できます。ユーザーの登録と登録解除は、外部ディレクトリにユーザーを追加または削除した際に自動的に実行されます。このようなユーザーディレクトリは通常、ID プロバイダーと呼ばれるソフトウェアベンダーからサービスとして提供されます。Atlassian Guard を使うと、アトラシアンのクラウド製品を ID プロバイダーと統合できます。

ユーザーのプロビジョニングと解除を
実装する理由

ユーザープロビジョニングによって、従業員が入社または別のチームに異動する際にアプリケーションのアクセス権を付与する手作業を減らせます。また、プロビジョニングの解除を自動化することで、退職した社員のアクセス権を削除して情報漏えいのリスクを軽減できます。さらに、従業員の退社や異動の際はユーザーアカウントが自動的に削除されるため、よりきめ細かくコスト管理できます。

仕組み

Atlassian Guard でユーザーディレクトリとアトラシアンのクラウド製品を統合することで、ID プロバイダーで行ったユーザーに関する更新が、アトラシアンの組織に自動的に同期されます。

新入社員が会社に加わると、おそらくはエンジニアリング・チームの IT 管理者が、普段自分たちが仕事で使っている少なくとも 10 個のアプリへのアクセス権を新入社員に付与することになります。ユーザー・プロビジョニングを設定しておけば、管理者はエンジニアリング・グループに従業員を一度追加するだけで、必要なアプリがすべて自動的にプロビジョニングされます。エンジニアが退職した場合も、管理者はユーザー・ディレクトリを 1 回変更するだけでアクセス権を取り消せます。

また、ある従業員がエンジニアチームから製品チームに異動したら、それまでと若干異なるツールセットを使用する必要があるかもしれません。このときも管理者の仕事はたった 1 つ、ユーザーディレクトリのグループ設定に変更を一度加えるだけです。これで不要になったツールへのアクセス権が取り消され、新しいツールのアクセス権が付与されます。

認証ポリシーとは

管理者は管理対象アカウントに認証ポリシーを設定して、認証設定をメンバーに適用できます。

ポリシーを通じて設定できる認証設定は次のとおりです。

• シングルサインオン (SSO)
• 2 段階認証 (2SV) の強制設定
• パスワード ポリシー (パスワードの強度と有効期限)
• セッション長

複数の認証ポリシーを適用する理由

組織内で複数の認証ポリシーを設定する理由は多数ありますが、主な理由は次のとおりです。

• 特定のユーザーのサブセットにポリシーを指定する
• 認証設定機能をテストする

仕組み

管理者は複数の認証ポリシーを柔軟に設定して組織内のユーザーのさまざまなサブセットにそれらのポリシーを適用し、ユーザーの各サブセットに適切なレベルのセキュリティを確保できます。

小規模なテスト グループにシングル サインオンを有効にすることで、別の認証ポリシーを設定して SAML 構成を組織全体に展開する前にテストできます。

2 段階認証の強制設定とは

2 段階認証の強制設定とはセキュリティポリシーであり、組織のユーザーにアトラシアンのクラウド製品にログインしてアクセスするために 2 段階認証を求めます。

2 段階認証の強制設定を使う理由

2 段階認証の強制設定によって、アカウントのパスワードが漏えいしてもアカウントを保護でき、アカウントからアクセスできる情報のセキュリティも向上します。

仕組み

2 段階認証の強制設定の適用時に既存の Atlassian アカウントがある場合は、アカウントから強制的にログアウトされ、次回ログイン時に 2 番目の認証方法を設定するよう求められます。初めて Atlassian アカウントを設定する場合は、登録フローの一環として 2 番目の認証方法を設定するよう求められます。

API トークン制御とは

API トークンにより、ユーザーはクラウド・アプリで認証し、REST API を通じてインスタンスからデータを取得できます。トークン制御により管理者は、管理対象ユーザーおよび外部ユーザーによる API トークンの使用を確認し、取り消せます。

API トークン制御を使う理由

ユーザー API トークン管理により、管理者はユーザー API トークン・ライフサイクルをより詳細に把握して制御できるようになり、組織のセキュリティ体制を強化できます。これには、次が含まれます。

• API トークンを介して、どのユーザーがデータにアクセスできるかをより細かく制御できる
• どのユーザーが API トークンを作成し、取り消しているかがより明確になり、攻撃者によるセキュリティ上の脅威を特定して対処できるようになる

ユーザーがアトラシアンで API トークンを作成して使用する方法をご覧ください

仕組み

管理者は、認証ポリシーの API トークン設定に移動して、管理対象ユーザーが新しいユーザー API トークンを作成できるか、既存のトークンを使用できるかを制御できます。

管理者は、組織内の管理対象アカウントに関連付けられているすべてのアクティブ・ユーザー API トークンをアトラシアンの管理で表示することもできます。これにより、管理者が特定ユーザーのアクセスを取り消したい場合、管理対象アカウントのそのユーザーのアカウント詳細に簡単に移動できます。

モバイル・アプリ・ポリシーとは

MAM（モバイル・アプリ管理）で、組織全体の柔軟性を高めましょう。MAM では、Jira Cloud、Confluence Cloud、Opsgenie モバイル・アプリ全体の BYOD（私用デバイスの利用）のセキュリティ制御を設定できます。

モバイル・アプリ・ポリシーを使う理由

モバイル・アプリ・ポリシーを実装することで、組織はコラボレーションを実現しながらユーザーとデータを保護するための制御を積極的に設定できます。モバイル・ポリシーを設定する際に、ユーザーのデバイスが組織に接続されているモバイル・アプリにアクセスできるようにするには、そのデバイスがセキュリティ要件を満たす必要があります。

仕組み

MAM ポリシーは、すべてのユーザー、または特定の管理対象ユーザーのサブセットに適用できます。MAM は、管理対象ユーザーと外部ユーザーの両方に対して使用できます。次のような MAM 機能を使って保護をさらに強化できます。

• コンテンツの共有、保存、バックアップを無効にする
• スクリーンショットと画面録画を無効にする
• コンテンツの切り取りやコピーを無効にする
• 侵害されたデバイスをブロックする
• データ暗号化、生体認証、またはデバイスのパスコードを必須にする
• OS バージョンの最小要件を指定する
• IP 許可リストを上書きして Jira と Confluence の各モバイル アプリからのアクセスを許可

製品の自動検出とは何ですか?

管理者は自身が管理しているユーザーが作成した Atlassian クラウド製品を発見することで、これらの製品の管理者とそれらの製品に加入しているユーザーの数を確認することによって、組織のシャドー IT を可視化して管理できます。

製品の自動検出はなぜ重要なのですか?

クラウドでは、組織の中央管理チームが認識または承認しているかどうかにかかわらず、ユーザーが簡単に新製品を作成できます。これは次のような事態を招く可能性があるため、管理者にとっては脅威です。

• コスト管理の欠如
• 運用の複雑さ
• セキュリティとコンプライアンスの懸念

自動製品検出を使用すれば、組織の管理者は組織内に存在するユーザー作成の Atlassian クラウド製品 (シャドー IT) を一貫して可視化できます。また、組織の管理者とこれらの製品を管理するユーザーが連携することによって、これらのシャドー IT 製品の管理が容易になります。シャドー IT の所有者に連絡することで、組織管理者は次を開始できます。

• 製品を削除することによって、請求とセキュリティに関する問題を軽減する
• ユーザーのニーズを満たす製品を IT 部門の承認を得て作成する
• 製品とデータを組織の公式製品に統合する

仕組み

Atlassian は、管理対象ユーザーが作成したシャドー IT 製品の数とそのシャドー IT 製品の特徴について正確に記述したメールを事前に送信します。

「admin.atlassian.com」では、組織管理者は、これらの製品の所有者、その製品に含まれるユーザー数、製品が作成された日付などの追加情報も確認できます。

修正を開始するため、組織の管理者は省略記号 "…" をクリックして、製品の所有者に連絡できます。

組織監査ログとは

組織のインサイトによって管理者は、アトラシアン製品の利用状況を追跡してユーザーのセキュリティ体制を評価できます。この機能によって、組織にリンクされている Jira と Confluence のクラウド製品全体を分析できます。

組織監査ログを使う理由

情報漏えい対策: 誰がどの製品インスタンスへのアクセス権を付与されたかを厳密に確認することにより、情報漏えい (例: 知的財産、健康または財務に関する機密データ) が起きた場合に、管理者はそのユーザーのアクセスを停止し、不審なアクティビティの詳細な記録を取得するようアクションを実行し、即座に必要なアクションを取れます。

アクティビティの監視: トラブルシューティングまたは根本原因分析シナリオにおいて、管理者はどのユーザーにいつアクセス権が付与されたかを即座に確認し、特定の時期に起きた問題に関連する可能性がある内容を特定できます。これは特にコンプライアンスと監査の目的に役立ちます。

コラボレーションの管理: 監査ログからの情報により、疑問に対する回答を得られます。「そのユーザーは、当該のページやプロジェクトを閲覧、編集してよいのか?」という疑問には、そのようなユーザーを削除できるようにする回答、または「このユーザーはアクセスできるはずの製品に、どのようにアクセスできなくなったのか?」という疑問には、アクセスを回復できるようにする回答を得られます。

仕組み

Atlassian Guard ダッシュボード内で、組織の管理者は監査ログを確認し、フィルターをかけられます。また、管理者は過去 6 か月間のアクティビティをダウンロードし、.CSV ファイルにエクスポートできます。

組織のインサイトとは

組織のインサイトによって管理者は、アトラシアン製品の利用状況を追跡してユーザーのセキュリティ体制を評価できます。この機能によって、組織にリンクされている Jira と Confluence のクラウド製品全体を分析できます。

組織のインサイトを使う理由

管理者はアトラシアン製品の利用状況をより詳細に把握し、利用率の向上や製品の ROI の最適化にあたって、よりデータ主導の決定を下せます。さらに、ユーザーのセキュリティに対する姿勢を一目で把握して、ユーザーと権限をよりプロアクティブに管理できます。

仕組み

管理者は組織管理ハブのセキュリティ セクションから、組織のインサイトにアクセスできます。このページでは、管理者は以下を実行できます。

1. 組織にリンクされている Jira や Confluence のクラウド製品全体における日次および月次のアクティブ ユーザーを表示
2. 現在のライセンス使用状況を確認し、アトラシアン製品がどれくらい使われているかを詳細に把握
3. 2 段階認証または SSO を有効化している管理対象ユーザー数を確認

当社は引き続きインサイトを追加して、管理者が組織レベルでセキュリティ対策と使用状況を把握できるようにします。

CASB とは?

Cloud Access Security Broker (CASB) はサードパーティ ソフトウェアであり、組織内で使用されるクラウド製品と統合することによって高度なクラウド セキュリティ機能を実現します。CASB ソフトウェアは各クラウド製品で送受信されるすべての情報を追跡して分析します。CASB ベンダーはこのデータを利用して、より優れた可視性、修復、脅威からの保護、ポリシー管理、データ セキュリティを実現できます。

Atlassian Guard で CASB を使用する理由

CASB ソフトウェアの McAfee MVISION Cloud と Atlassian Guard の統合によって、管理者は次のメリットを得られます。

• アトラシアンのクラウド製品を含むクラウド サービス全体のコンテンツとユーザー アクションを一元的に可視化
• 重要なアトラシアンのクラウド データを保存されている場所を問わず保護する機能が向上
• 疑わしいアクティビティの監視によって脅威からの保護を強化

Atlassian Guard では、McAfee MVISION Cloud がアトラシアンの組織レベルのアクティビティに関する完全な記録を取得して、機械学習を活用してアクティビティを分析し、脅威を正確に検出します。

仕組み

Atlassian Guard によってアトラシアンのクラウド製品のガバナンスを一元化してから CASB ソフトウェアの McAfee MVISION Cloud に接続し、McAfee MVISION Cloud ダッシュボードを介してセキュリティ監視と行動分析を自動化します。

次のステップ

おめでとうございます。Atlassian Guard の設定が完了しました。Atlassian Cloud 製品全体での不正アクセスや危険な行動を効果的に防ぐことに一歩近づきました。トライアルの後も Atlassian Guard の機能を引き続き使用するには、サブスクリプションにご登録いただく必要があります。

Atlassian Guard の価格の仕組み

ユニーク ユーザーごとに柔軟な価格設定を提供します。Atlassian Guard のユニーク ユーザーとは、1 ユーザーがアクセスできる製品の数にかかわらず、請求の際は 1 ユーザーとしてカウントされることを意味します。

Atlassian Guard のサブスクリプション価格は、組織の成長に合わせて最大の価値を得られるように設定されています。ユーザーを追加すると、ユーザーあたりの平均価格が下がります。

請求サイクル (月または年) ごとに、各ユーザーが使用する製品の数にかかわらず、Atlassian Guard がサポートする製品にプロビジョニングされているユニーク ユーザーの数に応じて請求されます。

つまり、ユーザーが Confluence と Jira の両方にプロビジョニングされていても、Atlassian Guard の請求時には単一のユーザーとしてカウントされます。