Atlassian Cloud アーキテクチャと運用プラクティス

アトラシアンのクラウド ホスティング アーキテクチャ

クラウド サービス プロバイダーとして AWS (Amazon Web Services) を採用して、世界中の複数のリージョンで高い可用性を備えたデータ センター施設を使用しています。各 AWS リージョンは、AZ (アベイラビリティ ゾーン) として知られる、複数の独立かつ物理的に分離されたデータ センター郡を備えた個別の地理的な場所を指します。

アトラシアンは、AWS のコンピューティング、ストレージ、ネットワーク、データ サービスを活用して、製品とプラットフォーム コンポーネントを構築しています。これによって、AWS が提供するアベイラビリティ ゾーンやリージョンなどの冗長性機能の利用が可能になっています。

可用性ゾーン

各アベイラビリティ ゾーンは他のゾーンの障害から隔離されて、同リージョンにある他の AZ に低コストで低遅延のネットワーク接続を提供できるように設計されています。このマルチゾーンの高可用性は地理的および環境面におけるリスクの防御の第一線であり、AZ の障害があってもマルチ AZ デプロイ環境で実行されるサービスは影響を受けません。

Jira と Confluence は、Amazon RDS (Amazon Relational Database Service) のマルチ AZ デプロイ モードを利用しています。マルチ AZ デプロイでは、Amazon RDS は同リージョンの異なる AZ において同期スタンバイ レプリカをプロビジョニングして維持し、冗長性とフェイルオーバー機能を提供します。AZ フェイルオーバーは自動化されて、通常は 60 〜 120 秒で実施されます。そのため、管理者による介入なしに、データベース オペレーションを可能な限り迅速に再開できます。Opsgenie、Statuspage、Trello、Jira Align も、レプリカとフェイルオーバーの各タイミングにわずかな差異はあるものの、同様のデプロイ戦略を使用しています。

データの場所

Jira と Confluence のデータは、大多数のユーザーのサインアップ時の場所に最も近いリージョンに保管されます。Bitbucket のデータは、米国東部の 2 つの異なる可用性ゾーンにあります。

ただし、特定の場所にデータを保存する必要があるお客様もいらっしゃるため、データ レジデンシーのオプションを提供しています。現在、データ レジデンシーは、米国、EU、英国、オーストラリア、カナダ、ドイツ、インド、日本、シンガポール、韓国、スイスの 11 のリージョンで、Jira、Jira Service Management、Jira Product Discovery、Confluence について利用できます。データ レジデンシーと関連する対象製品のデータについて詳しくは、アトラシアンのドキュメントをご覧ください。さらに、新製品、リージョン、データ タイプへの拡張など、データ レジデンシーの最新情報については、当社のロードマップで確認できます。

データ バックアップ

アトラシアンでは、包括的なバックアップ・プログラムを運用しています。これには、システム リカバリ要件に合わせてバックアップ対策が設計されている社内システムも含まれます。アトラシアンのクラウド製品の、特にお客様とそのアプリケーションのデータについては、広範なバックアップ対策も講じています。Amazon RDS (Relational Database Service) のスナップショット機能によって、RDS インスタンスごとの自動バックアップを毎日作成しています。

Amazon RDS スナップショットは、ポイントインタイム・リカバリ（特定時点への復元）をサポートできるよう 30 日間保持され、AES-256 暗号化を使用して暗号化されます。バックアップ・データはオフサイトに保存されませんが、特定の AWS リージョン内にある複数のデータ・センターにレプリケーションされます。また、四半期ごとにバックアップ テストを実施しています。

Bitbucket の場合、ストレージ・スナップショットはポイントインタイム・リカバリをサポートできるよう 7 日間保持されます。

これらのバックアップは、お客様による大幅な変更の復元には使用されません。これには、スクリプトによって上書きされたフィールド、削除された課題、プロジェクト、サイトなどの変更が含まれます。データの損失を避けるため、定期的なバックアップをお勧めします。ご利用の製品に関するバックアップ作成の詳細については、サポート・ドキュメントをご確認ください。

データ センターのセキュリティ

AWS では、データ センターの保護のために複数の認定を取得しています。これらの認定は、物理的および環境的なセキュリティ、システムの可用性、ネットワークと IP バックボーン アクセス、顧客のプロビジョニング、問題管理を目的としています。データ センターへのアクセスは権限を付与された人員に限られて、生体認証手段によって検証されます。物理的なセキュリティ対策には、常駐の警備員、有線のビデオ監視、侵入者用の装置、その他の侵入保護措置が含まれます。

分散型サービス アーキテクチャ

この AWS アーキテクチャによって、アトラシアンのソリューション全体で使用される多数のプラットフォームや製品サービスがホストされています。これには、メディア、アイデンティティ、コマース、エディターなどのエクスペリエンスなど、複数のアトラシアン製品全体で共有されて利用されるプラットフォーム機能のほか、Jira 課題サービスや Confluence アナリティクスなどの製品固有の機能が含まれます。

マルチテナント アーキテクチャ

クラウド インフラストラクチャに加えて、アトラシアンは製品をサポートする共有プラットフォームを備えたマルチテナント マイクロサービス アーキテクチャを構築して運用しています。マルチテナント アーキテクチャでは、クラウド製品の運用に必要なデータベースやコンピューティング インスタンスなど、単一のサービスを複数のお客様に提供します。各シャード (基本的にはコンテナー、下の図 3 参照) には複数のテナントのデータが含まれますが、各テナントのデータは分離されていて他のテナントからアクセスできません。アトラシアンではシングル テナント アーキテクチャを提供しておりませんので、ご注意ください。

テナントのプロビジョニングとライフサイクル

新規のお客様がプロビジョニングされると、一連のイベントによって分散型サービスの連携とデータ ストアのプロビジョニングがトリガーされます。これらのイベントは通常、ライフサイクルの次の 7 つのステップのいずれかにマッピングできます。

1. コマース システムでは当該のお客様に関する最新のメタデータとアクセス制御情報がすぐに更新されて、その後プロビジョニング連携システムで一連のテナントと製品イベントを通じて「プロビジョニングされたリソースの状態」がライセンスの状態と統一されます。

テナント イベント

テナント全体に影響を与えるイベントで、次のいずれかに当てはまります。

• 作成: テナントが作成され、新しいサイトに使用される
• 破棄: テナント全体が削除される

製品イベント

• アクティブ化: ライセンス製品またはサードパーティ アプリのアクティブ化の後
• 非アクティブ化: 特定の製品またはアプリの非アクティブ化後
• 一時停止: 特定の既存製品の一時停止後、所有する特定のサイトへのアクセスを無効にする
• 一時停止解除: 特定の既存製品の一時停止の解除後、所有するサイトへのアクセスを可能にする
• ライセンスの更新: 特定の製品のライセンスのユーザー数およびそのステータス (アクティブ/非アクティブ) に関する情報を含む

2. お客様のサイトを作成して、そのお客様に適した製品セットをアクティブ化します。サイトのコンセプトは、特定のお客様にライセンスされた複数の製品のコンテナーです (例: ＜site-name＞.atlassian.net の Confluence と Jira Software)。

テナントの分離

アトラシアンのクラウド製品をご使用いただく際に、お客様には一般的なクラウド ベースのインフラストラクチャを共有していただいていますが、あるお客様の行動によって他のお客様のデータやサービスが損われることがないように、論理的に分離する対策を講じています。

これを実現するためのアトラシアンのアプローチは、アプリケーションによって異なります。Jira Cloud と Confluence Cloud の場合は、お客様の間の論理的な分離を実現するために「テナント コンテキスト」という概念を使用しています。この概念は両方のアプリケーション コードに実装されて、アトラシアンが構築した「テナント コンテキスト サービス」(TCS) という仕組みで管理されます。この概念により、次が保証されます。

• それぞれのお客様のデータは、保存中に他のテナントから論理的に分離された状態にある。
• Jira または Confluence によって処理されるリクエストはテナント特有のビューで表示されるため、他のテナントに影響しない。

簡単に言うと、TCS は個々のお客様のテナントの「コンテキスト」を保管することによって機能します。各テナントのコンテキストは TCS によって一元的に格納される一意の ID に関連付けられて、そのテナントに関係する幅広いメタデータが含まれます。メタデータは、テナントが含まれるデータベース、テナントが所有するライセンス、アクセス可能な機能、その他の設定情報などです。お客様が Jira Cloud または Confluence Cloud にアクセスすると、TCS はテナント ID を使用してそのメタデータを照合します。その後、メタデータはテナントがセッション中にアプリケーション内で実行するあらゆる操作にリンクされます。

アトラシアン エッジ

お客様のデータは、アトラシアンでは「エッジ」と呼ばれる、ソフトウェアの周辺に構築される仮想的な壁によっても保護されています。リクエストを受信すると、最も近いエッジに送信されます。一連の検証を通じて、そのリクエストは許可または拒否されます。

• リクエストは、ユーザーに最も近いアトラシアン エッジに到達します。エッジは ID システムによって、ユーザーのセッションと ID を検証します。
• エッジは TCS 情報のデータに基づいて、製品データの場所を決定します。
• エッジはリクエストをターゲット リージョンに転送して、そのリクエストはコンピューティング ノードに到達します。
• ノードはテナント構成システムによってライセンスやデータベースの場所などの情報を決定して、他のさまざまなデータ ストアやサービス (画像や添付ファイルをホストするメディア プラットフォームなど) を呼び出してリクエストの処理に必要な情報を取得します。
• 元のユーザー リクエストには、他のサービスに対する過去の呼び出しから収集した情報が含まれます。

サービスの認証と承認

アトラシアンのプラットフォームでは、データのアクセスに最小権限を使用します。つまり、すべてのデータはデータの保存、処理、または取得に責任を持つサービスのみに制限されます。たとえば、メディア サービスでは複数のクラウド製品全体で一貫したファイル アップロードやダウンロードをご利用いただけますが、アトラシアンの他のサービスがアクセスできない専用のストレージが設定されています。メディア コンテンツへのアクセスを必要とするサービスは、メディア サービス API と連携する必要があります。その結果、サービス レイヤーでの強力な認証と承認によって、職務の分離やデータに対する最小権限のアクセスも強化されます。

アトラシアンは JSON Web Token (JWT) によってアプリケーションの外部で署名権限を確保しているため、ID システムとテナント コンテキストは信頼できる情報源です。トークンは、承認されている目的以外には使用できません。自分やチームのメンバーがマイクロサービスやシャードを呼び出すと、トークンが ID システムに渡されて検証されます。このプロセスによって、適切なデータの共有前にトークンが最新かつ署名されていることを確認します。これらのマイクロサービスにアクセスするために必要な承認と認証を組み合わせると、サービスがセキュリティ侵害を受けた場合は範囲が限定されます。

しかし、ID システムがセキュリティ侵害を受けることもあります。このリスクを軽減するために、アトラシアンでは 2 つのメカニズムを採用しています。まず、TCS と ID プロキシは高度に複製されます。ほぼすべてのマイクロサービスには TCS サイドカーがあり、認証権限に対して派生するプロキシ サイドカーを使用しているため、これらのサービスは常時何千も実行されています。1 つ以上のサービスに異常な動作が発生した場合は、その動作を迅速に発見してその課題を修正できます。

また、アトラシアンは、製品やプラットフォームに脆弱性が見つかるのを待っているわけではありません。これらの状況を積極的に特定することでお客様への影響を最小限に抑え、多数のセキュリティ プログラムを実行してセキュリティ脅威を特定して検出し、対処しています。

テナント コンテキスト サービス

アトラシアンでは、マイクロサービスへのリクエストには、アクセスを要求している顧客またはテナントに関するメタデータを必ず含むようにしています。これはテナント コンテキスト サービスと呼ばれて、プロビジョニング システムから直接入力されます。リクエストが開始されるとコンテキストが読み取られて、実行しているサービス コードに取り込まれます。このコードによってユーザーを承認します。Jira と Confluence におけるすべてのサービス アクセス、つまりデータ アクセスにはこのテナント コンテキストが必要で、ないとリクエストは拒否されます。

サービスの認証と承認は、アトラシアン サービス認証プロトコル (ASAP) を介して適用されます。明示的な許可リストによって通信できるサービスが判断されて、承認の詳細によって利用可能なコマンドとパスが指定されます。これによって、セキュリティ侵害を受けたサービスの潜在的なラテラル ムーブメントが制限されます。

サービスの認証と承認に加えてエグレスは、一連の専用プロキシによって制御されます。これによって、アプリケーション コードの脆弱性がこれらの制御に影響を与える可能性が取り除かれます。リモートでコードを実行するには、アプリケーション ロジックを変更できるだけでなく、基盤となるホストのセキュリティを侵害して Docker コンテナーの境界を迂回する必要があります。むしろ、アトラシアンのホスト レベルの侵入検出で不一致フラグが設定されます。

これらのプロキシでは、意図されたサービスの動作に基づき、エグレス動作が制限されます。Webhook を発行する必要のない、またはマイクロサービスとの通信を禁止されている他のマイクロサービスと通信する必要のないサービスです。

データ暗号化

アトラシアン クラウド製品では、転送中のお客様データは TLS 1.2 以降で暗号化され、Perfect Forward Secrecy (PFS) によって不正な情報漏えいやデータ改変から保護されます。アトラシアンは、NIST が推奨する TLS 1.2+ プロトコルを使用しています。このプロトコルでは、ブラウザがサポートする強力な暗号とキー長の使用が義務付けられています。

Jira Software Cloud、Jira Service Management Cloud、Jira、Bitbucket Cloud、Confluence Cloud、Statuspage、Opsgenie、Trello などのクラウド サービスに保管されるお客様データおよび添付ファイルは、保存時は業界標準の AES-256 暗号化で保護されます。

個人を特定できる情報 (PII) の転送は、暗号化と、意図された宛先にデータが安全に転送されるように設計された堅牢なデータ アクセス制御によって保護されます。アトラシアンの暗号技術と暗号化ポリシーでは、PII の保存と転送に関するリスクを軽減するため、暗号技術と暗号化の実装に関する原則を定めています。PII を保護するための暗号化アルゴリズムは、アトラシアン内部のデータ セキュリティと情報のライフサイクル管理ポリシーに従い、PII の機密レベルに合わせて決定されます。これにより、機密データはその分類に基づいて適切に保護されます。アトラシアンがお客様のデータを収集、共有、使用する方法に関する詳細については、プライバシー ページをご参照ください。

データ暗号化の追加機能に関する最新状況については、クラウド・ロードマップをご確認ください。