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 について利用できます。データ レジデンシーと関連する対象製品のデータについて詳しくは、アトラシアンのドキュメントをご覧ください。さらに、新製品、リージョン、データ タイプへの拡張など、データ レジデンシーの最新情報については、当社のロードマップで確認できます。

データ バックアップ

We operate a comprehensive backup program at Atlassian. This includes our internal systems, where our backup measures are designed in line with system recovery requirements. With respect to our cloud apps, and specifically referring to you and your application data, we also have extensive backup measures in place. We use the snapshot feature of Amazon RDS (Relational database service) to create automated daily backups of each RDS instance.

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

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

We don’t use these backups to revert customer-initiated destructive changes, such as fields overwritten using scripts, or deleted work items, projects, or sites. To avoid data loss, we recommend making regular backups. Learn more about creating backups in the support documentation for your product.

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

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

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

With this AWS architecture, we host a number of platform and product services that are used across our solutions. This includes platform capabilities that are shared and consumed across multiple Atlassian products, such as Media, Identity, and Commerce, experiences such as our Editor, and product-specific capabilities, like Jira Work Item service and Confluence Analytics.

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

On top of our cloud infrastructure, we built and operate a multi-tenant micro-service architecture along with a shared platform that supports our products. In a multi-tenant architecture, a single service serves multiple customers, including databases and compute instances required to run our cloud apps. Each shard (essentially a container – see figure 3 below) contains the data for multiple tenants, but each tenant's data is isolated and inaccessible to other tenants. It is important to note that we do not offer a single tenant architecture.

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

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

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

テナント イベント

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

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

製品イベント

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

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

テナントの分離

While our customers share a common cloud-based infrastructure when using our cloud apps, we have measures in place to ensure they are logically separated so that the actions of one customer cannot compromise the data or service of other customers.

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

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

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

アトラシアン エッジ

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

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

サービスの認証と承認

Our platform uses a least privilege model for accessing data. This means that all data is restricted to only the service responsible for saving, processing, or retrieving it. For example, the media services, which allows you to have a consistent file upload and download experience across our cloud apps, have dedicated storage provisioned that no other services at Atlassian can access. Any service that requires access to the media content needs to interact with the media services API. As a result, strong authentication and authorization at the service layer also enforces strong separation of duties and least privilege access to data.

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

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

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

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

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

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

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

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

データ暗号化

Customer data in Atlassian cloud apps is encrypted during transmission utilizing TLS 1.2 or higher, incorporating perfect forward secrecy (PFS) to safeguard against unauthorized information disclosure and data modification. We adhere to NIST-recommended TLS 1.2+ protocols, which enforce the use of strong ciphers and key lengths as supported by the browser.

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

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

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