| 原則 1: 転送中のデータ保護 |
| 1.1 暗号化 | アトラシアンでは、デフォルトのベンダー設定の変更を含め、内部ワイヤレス ネットワークの暗号化を管理しています。アトラシアンのワークプレース テクノロジー チームは、WPA2-AES 認証と PEAP-EAP-MSCHAPv2 暗号化を利用してワイヤレス ネットワークを保護しています。当社のワイヤレス ネットワークについては社内の ID ストアを利用して 802.1x 経由で認証しています。不正なワイヤレス アクセス ポイントがないか定期的にスキャンし、見つかった不正アクセス ポイントのリストを管理しています。
アトラシアンは、業界標準の 、TLS (Transport Layer Security) バージョン 1.2 を使用して、高度暗号化標準 256 ビット (AES) 暗号化を使用して安全な接続を確立しています。ユーザー データを保存するサーバーでは、業界標準のフルディスク AES 暗号化を採用します。テナント データは AWS RDS または RDS バックアップ内で暗号化され、すべての添付ファイルと同様に長期ストレージ (S3) でも暗号化されます。
詳細については、https://www.atlassian.com/trust/security/security-practices#encryption-and-key-management を参照してください。 | 当社のセキュリティおよびデータプライバシーに関するポリシー
データの暗号化 | Atlassian Trust Center データ
暗号化 | Atlassian Cloud アーキテクチャと運用プラクティス |
| 1.2 ネットワーク保護 | アトラシアンのポリシー管理プログラム (PMP) には、ネットワーク管理の責任範囲を定めた通信セキュリティ ポリシーが含まれています。
アトラシアンでは、ネットワーク アクセスには、一元化された LDAP 対応ディレクトリを使用し、定義済みのプロファイルに基づくロール ベースのアクセス制御を実装しています。ユーザーには、当社の人事管理システムからのワークフローを介して、これらのプロファイルに基づく適切なアクセス権が付与されます。社内本番環境のネットワークのアクセス ルールは、AWS VPC 環境内で明示的に指定されたセキュリティ グループを使用して管理されています。
アトラシアンのワークプレース テクノロジー チームは、WPA2-AES 認証とPEAP-EAP AP-MSCHAPv2 暗号化を利用してワイヤレス ネットワークを保護しています。当社のワイヤレス ネットワークについては社内の ID ストアを利用して 802.1x 経由で認証しています。
アトラシアンのネットワーク エンジニアリングは、クラウドとオフィスのファイアウォールに組み込まれた IPS テクノロジーを使用しており、オフィス環境には IDS テクノロジーを実装しています。ネットワーク脅威対策は、DDoS 保護や一部の Web アプリケーション ファイアウォール機能を含め、AWS によって実施されています。
当社のサービスのデータはすべて、不正な開示や変更を防止するため、HTTPS か SMTPS かを問わず、TLS を使用して転送中に暗号化されます。アトラシアンの TLS の導入により、強力な暗号の使用が強制されています。 | 当社のセキュリティおよびデータプライバシーに関するポリシー
ネットワーク インフラストラクチャへのセキュリティの組み込み | Atlassian Trust Center |
| 1.3 認証 | アトラシアンは、このアクセスを職務や責任上、必要とする人員のみに限定しています。第 1 層のシステムはすべて、アトラシアンで一元化されたシングル サインオン (SSO) とディレクトリ ソリューションで管理されています。ユーザーには、当社の人事管理システムからのワークフローを介して、これらのプロファイルに基づく適切なアクセス権が付与されます。アトラシアンは MFA を利用して第 1 層システムのすべてにアクセスしています。ハイパーバイザー管理コンソールと AWS API への 2 要素認証と、ハイパーバイザー管理機能へのすべてのアクセスに関する毎日の監査レポートを有効にしています。ハイパーバイザー管理コンソールと AWS API へのアクセス・リストは四半期ごとに見直されます。また、人事システムと ID ストアの間で 8 時間ごとの同期を維持しています。
アトラシアンでは、ほとんどの製品の認証で Google、Microsoft、Apple の ID の使用をサポートしています。また、Atlassian Access を介した Atlassian Cloud サービスの SAML もサポートしています。https://www.atlassian.com/enterprise/cloud/access を参照してください。 | 当社のセキュリティおよびデータプライバシーに関するポリシー
ゼロ トラストによる社内ネットワークへのアクセス保護 | Atlassian Trust Center Service
認証と承認 | Atlassian Cloud アーキテクチャと運用プラクティス |
| 原則 2: 資産保護と回復力 |
| 2.1 物理的な場所と法的管轄 | 物理的な場所
、現在、アトラシアンは米国、ドイツ、アイルランド、シンガポール、オーストラリアで Data Center を保有し、データをホストしています。当社は、お客様のコンテンツを世界中の複数のリージョンでホストすることで、すべてのお客様に安全かつ高速で信頼性の高いサービスを提供しています。
Atlassian Cloud の本番環境システムはすべて、Amazon AWS の米国東部および米国西部のリージョン、AWS アイルランド リージョン、AWS フランクフルト リージョン、AWS シドニー リージョン、AWS シンガポール リージョンにあります。
アトラシアンのプラットフォームは、サインアップ時にアクセス元に基づいてお客様のデータの最適な常駐場所を選定することで、より信頼性の高いパフォーマンスを確保するとともにレイテンシーを減らします。
現在、データ レジデンシーは、Jira Software、Confluence、Jira Service Management の Standard、Premium、Enterprise の各クラウド プランの一部としてご利用いただけます。また、特定の製品データのホスティング場所をオーストラリア、ヨーロッパ、または米国から選択できます。データ レジデンシーの制御に関する詳細をご確認ください。
また、当社のクラウド ロードマップでは、データ レジデンシーを確保するための場所の追加やアプリのためのデータ レジデンシーなどを含めて、最新の情報をご参照いただけます。 | 物理的な場所
データの安全性確保 | Atlassian Trust Center
Atlassian Cloud ホスティング インフラストラクチャ | Atlassian Cloud アーキテクチャと運用プラクティス |
| データの使用
アトラシアン カスタマー アグリーメント、プライバシー ポリシー、およびデータ処理補遺を参照してください。 | データの使用
アトラシアン カスタマー アグリーメント | アトラシアン
プライバシー ポリシー | アトラシアン
データ処理補遺 | アトラシアン |
| その他の考慮事項
アトラシアンの GDPR に対する取り組みとその他のデータ保護規制を参照してください。 | その他の考慮事項
GDPR に対する取り組み | アトラシアン | アトラシアン |
| 2.2 データ センターのセキュリティ | これはアトラシアンのデータ処理補遺に記載されており、アトラシアンは、データ センターやネットワークのセキュリティ、データのセキュリティなど、お客様のデータを保護することを約束しています。
アトラシアンはデータ センターへの物理的な脅威を予測し、これらの脅威による影響を防止または制限するための対策を講じます。
アトラシアンのオフィスは、物理的な出入り口の監視などを含め、社内の物理および環境面でのセキュリティ ポリシーに従っています。
当社パートナーのデータ センターは、複数のコンプライアンス認証を取得しています。これらの認定は、物理的なセキュリティ、システムの可用性、ネットワークと IP バックボーン アクセス、顧客のプロビジョニング、問題管理を目的としています。データ センターへのアクセスは権限を付与された人員に限られて、生体認証手段によって検証されます。物理的なセキュリティ対策には、常駐の警備員、有線のビデオ監視、侵入者用の装置、その他の侵入保護措置が含まれます。
AWS では、データ センターの保護のために複数の認定を取得しています。AWS の物理的な保護に関する保証情報については、http://aws.amazon.com/compliance/ をご覧ください。 | https://www.atlassian.com/trust/security/securitypractices#physical-security を参照してください
|
| 2.3 データの暗号化 | アトラシアンでは、デフォルトのベンダー設定の変更を含め、内部ワイヤレス ネットワークの暗号化を管理しています。アトラシアンのワークプレース テクノロジー チームは、WPA2-AES 認証と PEAP-EAP-MSCHAPv2 暗号化を利用してワイヤレス ネットワークを保護しています。当社のワイヤレス ネットワークについては社内の ID ストアを利用して 802.1x 経由で認証しています。不正なワイヤレス アクセス ポイントがないか定期的にスキャンし、見つかった不正アクセス ポイントのリストを管理しています。
アトラシアンは、業界標準の 、TLS (Transport Layer Security) バージョン 1.2 を使用して、高度暗号化標準 256 ビット (AES) 暗号化を使用して安全な接続を確立しています。ユーザー データを保存するサーバーでは、業界標準のフルディスク AES 暗号化を採用します。テナント データは AWS RDS または RDS バックアップ内で暗号化され、すべての添付ファイルと同様に長期ストレージ (S3) でも暗号化されます。詳細については、https://www.atlassian.com/trust/security/security-practices#encryption-and-key-management を参照してください。 | 当社のセキュリティおよびデータプライバシーに関するポリシー
データの暗号化 | Atlassian Trust Center
データ暗号化 | Atlassian Cloud アーキテクチャと運用プラクティス |
| 2.4 データの消去と装置の廃棄 | アトラシアンは、さまざまな種類のデータをどのくらいの期間、保持しなければならないかを示すデータ保持および破壊基準に従っています。データは、アトラシアンのデータ セキュリティおよび情報のライフサイクル ポリシーに従って分類され、それに基づいてコントロールが実装されます。
顧客データについては、アトラシアンとの契約が終了すると、顧客チームに属するデータは本稼働中のデータベースから削除され、アトラシアンに直接アップロードされた添付ファイルはすべて 14 日以内に削除されます。チームのデータは暗号化され、バックアップに残りますが、90 日間のバックアップ保持期間を過ぎるとアトラシアンのデータ保持ポリシーに従って破棄されます。データ削除が要求されてから 90 日以内にデータベース復元が必要になった場合、運用チームは、本稼働中のシステムが完全に復元された後、可能な限り速やかにデータを再削除します。詳細については、https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/ を参照してください。 | データの保持と削除 | Atlassian Trust Center
ストレージを追跡し、製品間でデータを移動する | アトラシアン サポート |
| 2.5 物理的な回復力と可用性 | アトラシアンのオフィスにおける物理的なセキュリティ コントロールは、物理的および環境的なセキュリティ ポリシーに基づき、オン プレミスおよびクラウドの環境全体で堅牢な物理的セキュリティが確実に実施されるようにしています。このポリシーでは、安全な作業場所などのエリアをカバーし、任意の場所の IT 機器を保護し、建物やオフィスへのアクセスを適切な人員に限定し、物理的な出入口を監視します。当社の物理的なセキュリティ プラクティスには、勤務時間中の受付の在席、訪問者の登録要件、すべての非公共エリアへのバッジによるアクセスなどが含まれます。また、正面玄関と搬入口などの出入口での業務時間外のアクセスやビデオ録画について、オフィス ビル管理者と連携しています。
パートナーのデータ センターは、最低でも SOC-2 に準拠しています。これらの認定では、物理的および環境的なセキュリティと保護を含む、さまざまなセキュリティ・コントロールに取り組んでいます。データ センターへのアクセスは、権限を付与された人員に限られ、生体認証手段によって検証されます。物理的なセキュリティ対策には、常駐の警備員、有線でのビデオ監視、侵入者用の装置、その他の侵入保護措置が含まれます。
上記の対策に加え、当社の Statuspage 製品を使用して、サービス可用性の状況をお客様にリアルタイムで公開しています。当社製品で問題が発生した場合、当社で確認できた時点で、お客様にもご確認いただけます。 | 物理的セキュリティ | Atlassian Trust Center |
| 原則 3: 顧客の分離 |
| | アトラシアン製品をご使用いただく際に、お客様には一般的にクラウド ベースの IT インフラストラクチャを共有していただいていますが、あるお客様の行動が他のお客様のデータやサービスを損なうことがないように、論理的に分離する対策を講じています。
これを実現するためのアトラシアンのアプローチは、アプリケーションによって異なります。Jira Cloud および Confluence Cloud の場合、お客様の間の論理的な分離を実現するために、「テナント コンテキスト」という概念を使用しています。この概念は、両方のアプリケーション コードに実装され、当社が構築した「テナント コンテキスト サービス」(TCS) というしくみで管理されます。この概念によって、次が保証されます。
- それぞれのお客様のデータは、保存中に他のテナントから論理的に分離された状態にある。
- Jira または Confluence によって処理されるリクエストには「テナント特有」のビューで表示され、他のテナントに影響しない。
簡単に言うと、TCS は、個々のお客様のテナントの「コンテキスト」を保管することによって機能します。各テナントのコンテキストは、TCS によって一元的に格納される一意の ID に関連付けられ、そのテナントに関係する幅広いメタデータ (テナントが含まれるデータベース、テナントが所有するライセンス、アクセス可能な機能、その他の設定情報など) が含まれます。お客様が Jira Cloud または Confluence Cloud にアクセスすると、TCS はテナント ID によってそのメタデータを照合します。その後、メタデータはテナントがセッション中にアプリケーション内で実行するあらゆる操作にリンクされます。
TCS が提供するコンテキストは、お客様データとのやりとりが発生する際の「レンズ」の役割を果たし、このレンズが常に 1 つの特定のテナントに限定されます。そのため、あるお客様のテナントが別のテナントのデータにアクセスすることも、別のテナントがそのアクションによって別のテナントのサービスに影響を与えることもありません。
クラウド アーキテクチャの詳細については、「クラウド サポート リソース」にも一部記載がありますので、ご覧ください。 | Atlassian Cloud アーキテクチャと運用プラクティス | Atlassian Trust Center |
| 原則 4: ガバナンスの枠組み |
| | アトラシアンは、リスク評価の一環として、サービスの社内コントロール、システム、データ セキュリティ、プライバシー保護について規制対象機関による見直しが必要であることを認識しています。アトラシアンは毎年、自社の業務と内部コントロールを検証するために、独立した複数の第三者監査を受けています。
現在のコンプライアンス プログラムを確認するには、コンプライアンスのリソース センターにアクセスし、ダウンロード可能な当社製品の検証と認証をすべてご覧ください。
アトラシアンには、COSO リスク モデルと ISO 31000 に沿ったエンタープライズ リスク管理 (ERM) プログラムがあります。ERM プログラムでは、アトラシアン全体でリスク管理の枠組みと方法論を導入し、製品環境の年次リスク評価と定期的な特定リスク評価、および機能リスク評価を適宜、リスク プロファイルに基づいて実施します。
特に、アトラシアンのリスク管理フレームワークは、リスク評価活動を実施するための基準、プロセス、役割と責任、リスクに対する許容度、方向性を規定しています。アトラシアンのリスク管理プロセスとプラクティスは繰り返し可能であり、有効かつ一貫性のある、比較可能な結果を生み出すリスク評価を実現します。アトラシアンが実施するリスク評価には、すべてのリスク カテゴリの可能性と影響、および社内で設定したリスク選好を超えるあらゆるリスクへの措置が組み込まれています。ERM プログラムの全段階を通じて、リスクおよびコンプライアンス チームは関係する関係者と話し合い、該当する中小企業と協議します。 | 当社のセキュリティおよびデータプライバシーに関するポリシー
コンプライアンスとリスク管理 | Atlassian Trust Center
当社の Atlassian Trust Management System (ATMS) | Atlassian Trust Center
データ処理補遺 | Atlassian Trust Center |
| 原則 5: 運用上のセキュリティ |
| 5.1 脆弱性管理 | アトラシアンは、製品、サービス、インフラストラクチャにおける脆弱性の重大度と頻度の低減、および特定された脆弱性を可能な限り迅速に解消することに努めています。このため、アトラシアンでは、アプリケーションとインフラストラクチャ全体で脆弱性を特定、追跡し、これを修復する自動および手動のプロセスを使用する、多面的で絶えず進化し続ける脆弱性管理の方法を採用しています。
すべての製品とサービスについて、広範囲にわたるバグ修正プロセスがあります。つまり、課題を把握し、リクエストの解決に役立つ自社製品の Jira を活用しています。これを支えているのが、アトラシアンが遵守しているさまざまなセキュリティ バグ修正ポリシー、アドバイザリ サービス、SLO です。アトラシアンはサポート チャンネル、バグ報奨金プログラム、および security@atlassian.com を通じてバグ報告を受け付けています。セキュリティ バグ修正 SLO (https://www.atlassian.com/ja/trust/security/bug-fix-policy) の詳細については、当社の Trust Center (https://www.atlassian.com/ja/trust) をご覧ください。
アトラシアン セキュリティ チームでは、複数の方法を使って社内外のインフラストラクチャの脆弱性を検出しています。追跡と修復のために Jira チケットが作成され、重大度と脆弱性の原因に基づき、SLO に従って期限が割り当てられます。特定された脆弱性に関するチケットをシステム所有者に発行する継続的なプロセスがあり、セキュリティ管理チームが報告された脆弱性を確認し、それ対して対策が講じられていることを確認しています。
詳細については、アトラシアンの脆弱性管理方法の専用ページをご覧ください。
当社のセキュリティ テストに対するアプローチの詳細についても、Trust Center で社外セキュリティ テストに対するアプローチ | アトラシアンをご覧ください | 脆弱性管理 | Atlassian Trust Center
セキュリティ バグ修正ポリシー | Atlassian Trust Center
社外セキュリティ テストに対するアプローチ | Atlassian Trust Center
脆弱性管理方法 | Atlassian Trust Center |
| 5.2 保護モニタリング | 脅威がますます複雑化する状況で、アトラシアンではインシデント管理へのアプローチを強化する必要性を認識し、「セキュリティ検出プログラム」を導入しました。検出とは、アトラシアンのセキュリティ インシデントおよびイベント管理プラットフォームでスケジュールに基づいて積極的に検索を行い、当社とお客様をターゲットとする悪意あるアクティビティを捕捉することです。
当社の検出・対応チームは、新しい検出の定期的な作成、既存の検出のチューニングと改善、および検出対応の自動化に重点を置いています。これらの措置は、製品、攻撃タイプ、ログ ソースなど、さまざまな次元にわたって行い、検出が可能な限り効果的で包括的となるよう万全を期しています。
このプログラムは、現在直面している脅威に対する準備が整っていることを確認するだけでなく、将来の脅威の状況についても十分に予測し、準備することを目的としています。また、検出・対応チームは、当社で作成した検出を標準化するためのツールも作成しました。これにより、実行する検出は高レベルの整合性と品質を確保しており、業界随一であると私たちは確信しています。
当社はオフィス サイトとクラウド ホスティング環境に IDS を導入しました。Atlassian Cloud Platform については、ログ転送をセキュリティ分析プラットフォームに統合しました。ログが読み取り専用となっている各システムから、重要なシステム ログが中央のログ記録用プラットフォームに転送されます。アトラシアン セキュリティ チームでは、セキュリティ分析プラットフォーム (Splunk) 上でアラートを作成し、セキュリティ侵害の兆候を監視します。SRE チームでは、このプラットフォームを使用して、可用性またはパフォーマンスの課題を監視します。ログは、ホット バックアップで 30 日間、コールド バックアップで 365 日間保持されます。
アトラシアンの検出プログラムの詳細については、https://www.atlassian.com/trust/security/detections-program を参照してください。 | アトラシアンの検出プログラム | Atlassian Trust Center
ログの利用 | Atlassian Trust Center
データ処理補遺 | Atlassian Trust Center |
| 5.3 インシデント管理 | アトラシアンには、セキュリティ インシデント対応のための包括的なアプローチがあります。アトラシアンではセキュリティ インシデントを、お客様のデータ、アトラシアンのデータ、またはアトラシアンのサービスの機密性、完全性、可用性に悪影響を及ぼすあらゆるインスタンスであると捉えています。
明確に定義された当社の社内フレームワークには、さまざまなインシデント タイプに関して文書化されたプレイブックが含まれます。このフレームワークでは、インシデント対応のすべての段階で行う必要がある手順を網羅し、プロセスの一貫性、反復性、効率性を確保しています。その手順には、インシデントの検知と分析、インシデントの分類、封じ込め、根絶と復旧が含まれます。この一貫性は、インシデント対応プロセスの一部として、Confluence、Jira、Bitbucket などの自社製品を使用することでサポートされています。
- Confluence は、一元的な場所で当社の対応プロセスを作成、文書化、更新するために使用。
- Jira は、セキュリティ インシデント (発生する可能性がある、および実際に発生した) の対応プロセスの進捗を最初から最後まで追跡するためのチケット作成に使用。
- Bitbucket は、特定のインシデントで発生する特定のエッジケースの問題に対応するためのコードベースのソリューションを開発するインスタンスで使用。
当社の製品とインフラストラクチャを包括的かつ一元的に記録し、監視することで、潜在的なインシデントを迅速に検出できます。これは、高度な能力を持ち、効果的な対応を調整した実績のあるオンコール インシデント マネージャーのチームによってサポートされます。また、できる限り効果的な調査と対応を行うため、さまざまな外部エキスパートに支援を依頼することもあります。
お客様のデータが確認済みのインシデントに関与している場合は、通知プロセスと、インシデント後の堅牢なレビュー プロセスも備えているため、インシデントからあらゆる教訓を得てプラクティスを改善し、今後、悪意のある攻撃を受けにくくなります。詳細については、Atlassian Trust Center に記載の「セキュリティ インシデントの管理に対する当社のアプローチ」をご覧ください。 | インシデント管理 | Atlassian Trust Center
データ処理補遺 | Atlassian Trust Center |
| 5.4 構成と変更管理 | 当社の変更管理プロセスは、従来のものとは若干異なります。従来の変更管理プロセスは、ピラミッド形式の変更管理階層で実装されていました。つまり、変更を行う場合、変更内容を承認または却下するための会議で提案を行う必要があります。
当社では、「ピア レビュー、グリーン ビルド」(PRGB) 形式というオープン ソース スタイルのアプローチを採用しています。従来の変更管理プロセスとは対照的に、PRGB アプローチでは、変更ごとに (コードの変更であれ、インフラストラクチャの変更であれ) 1 人以上の同僚がレビューを行い、変更に伴う潜在的な問題を特定します。レビュー担当者の数は、変更の重要度や変更が影響を与えるシステムの重要度に応じて増やします。エンジニアは問題を特定してフラグを立て、変更を完了できるようにします。このプロセスでは、当社の環境における変更管理を動的かつ柔軟に実行できます。このコントロールでのグリーン ビルドの部分とは、新たな変更を含めた CI/CD で成功した、クリーン ビルドを指します。変更により導入されたコンポーネントが、統合、機能、ユニット、セキュリティに関するテストのいずれかで不合格となった場合、ビルドは却下され、元の変更リクエストに戻って問題に対処します。
アトラシアンは現在、従来の「品質保証 (Quality Assurance)」ではなく https://www.atlassian.com/inside-atlassian/quality-assurance-vs-quality-assistance の「品質支援 (Quality Assistance)」を利用するアプローチに注目しています。 | 当社環境における変更の管理 | Atlassian Trust Center
品質保証 (Quality Assurance) から品質支援 (Quality Assistance) への移行方法 |
| 原則 6: 人的セキュリティ |
| | アトラシアンの価値観
アトラシアンの価値観についての詳細は https://www.atlassian.com/company/values をご覧ください。
| アトラシアンの価値観
アトラシアンの価値観 | アトラシアン
|
| 従業員の身元確認
世界各国で、アトラシアンの新入社員には、身元確認を行うことが求められます。買収によって新たに雇用された社員については、買収後に身元確認が行われます。犯罪歴の確認は、すべての新入社員と独立した請負業者に対して一律に実施されます。役割や役職に必要であれば、学歴検証、職歴検証、与信確認が追加されます。上級管理職や経理職については特に身元確認を徹底しています。 | 社員の身元確認
身元確認 | Atlassian Trust Center |
| アトラシアン全社員を対象としたセキュリティ トレーニング
アトラシアンでは、オンボーディング トレーニング (「Day 1」) の一環として新入社員向けに、また全スタッフに対して継続的な情報セキュリティ トレーニングを提供しています。
この一般的な情報セキュリティ トレーニングに加えて、開発者向けとして組み込みセキュリティ エンジニア プログラムが支援するセキュア コーディングに的を絞ったトレーニングを提供しています。
また、マルウェア、フィッシング、その他のセキュリティ問題に関連するトピック別トレーニングも継続的に提供しています。セキュリティ意識 | Atlassian Trust Center | アトラシアン全社員を対象としたセキュリティ トレーニング
セキュリティ意識 | Atlassian Trust Center |
| 原則 7: 安全な開発 | アトラシアンは開発ライフサイクルのすべてのフェーズで、安全な開発を実践しています。詳細については、https://www.atlassian.com/trust/security/security-in-development をご覧ください。
設計フェーズの実践には脅威モデリング、設計レビュー、セキュリティ基準の定期更新ライブラリがあり、適切なセキュリティ要件を考慮しています。
開発中、最初のセキュリティ レビューとしては、必須のピア レビューがあります。これは自動での静的分析チェック (SAST) と手動でのセキュリティ テスト (どちらもリスク評価プロセスで規定されている社内チームとサードパーティの専門家によるもの) に支えられています。開発はアプリケーションのセキュリティ トレーニング プログラム、およびセキュリティ チームが保持しているセキュリティのナレッジ ベースにも支えられています。
次に、正式な運用準備と変更管理のプロセスにより、承認された変更のみが本番環境に展開されます。デプロイ後は、定期的な自動脆弱性スキャンと業界をリードするバグ報奨金プログラム (アトラシアンのバグ報奨金プログラム | Bugcrowd ) を利用して、当社アプリケーションを継続的に保証します。
さらに、アトラシアンの SOC レポートも確認できます。このレポートは、セキュリティ、可用性、処理の完全性、機密性、プライバシーに関連する組織のシステムを評価することを主眼としています。 | データ処理補遺 | Atlassian Trust Center |
| 原則 8: サプライ チェーンのセキュリティ | アトラシアンがサードパーティのサプライヤー (請負業者およびクラウド サービス プロバイダーなど) と契約関係にある場合、契約により当社のお客様またはお客様のデータが危険にさらされることがないよう注力しています。このため、サードパーティのサプライヤー契約の締結では、当社の法務チームおよび調達チームがレビュー プロセスを実施します。高リスクまたは重大なリスクと思われる契約については、セキュリティおよびリスク、コンプライアンスの各チームによる追加のレビューが必要となります。レビュー後には継続的なデュー デリジェンスも発生し、契約のリスク レベルに応じて契約更新時または年単位でレビューを行います。
また、アトラシアンでは、契約を締結するサプライヤーに、最低限のセキュリティ要件を遵守するよう要請しています。これらの要件は、サプライヤー契約条項に含めることによって施行されます。セキュリティ要件は、契約のリスク レベルに応じて異なり、次のものが含まれます。
- アトラシアンのシングル サインオン プラットフォームとの SAML 統合
- 適切なアルゴリズムを使用した転送中および保存中のデータの暗号化
- 潜在的なセキュリティ インシデントに関する適切な情報をアトラシアンに提供するための十分なログ メカニズムを備えていること
| サプライヤー リスク管理 | Atlassian Trust Center
| Atlassian SOC 2 | 29 ページ (ベンダー管理) |
| 原則 9: 安全なユーザー管理 |
| 9.1 管理インターフェイスとサポート チャンネルへのユーザーの認証 | アトラシアンでは、これをお客様とアトラシアン両方が共有すべき責任だととらえています。
認証ユーザー
当社ではすべてのお客様データを平等に機密情報として扱い、これを統括する厳重な制限を適用しています。従業員や契約社員に対し、研修プログラム受講時に啓蒙トレーニングを実施して、お客様データの重要性と取り扱いのベスト プラクティスを教育しています。
Atlassian では、許可された社員のみが、アプリケーションに保管されているお客様データへのアクセス権を持ちます。パスフレーズで保護された個別の公開キーを使用して認証を行い、サーバーでの受信トラフィックでは、Atlassian および内部のデータ センターを経由した SSH 接続のみが許可されます。2FA を必要とする追加の認証要求と確認がない限り、アクセスできるのは権限を有するグループに限られます。
当社のグローバル サポート チームは、厳格な認証および権限のコントロールにより、保守とサポートのプロセスを容易にします。ホストされているアプリケーションやデータへのアクセスは、アプリケーションの健全性の監視、システムまたはアプリケーションの保守、または当社のサポート システム経由でのお客様からの依頼に基づいて行います。また、お客様には、当社の同意コントロール チェッカーを介して、サポート エンジニアがデータへのアクセスに適切であると明示的に同意するというオプションも提供されています。
お客様データへの許可されていないアクセスや不適切なアクセスは、セキュリティ インシデントとして扱い、当社のインシデント管理プロセスを通じて管理します。このプロセスには、ポリシー侵害があった場合の、影響を受けるお客様への通知も含まれます。 | お客様データへのアクセスの制御 | Atlassian Trust Center
データ処理補遺 | Atlassian Trust Center |
| 9.2 管理インターフェイス内の分離とアクセス制御 | この AWS アーキテクチャによって、アトラシアンのソリューション全体で使用される多数のプラットフォームや製品サービスがホストされています。これには、メディア、アイデンティティ、コマース、エディターなどのエクスペリエンスなど、複数のアトラシアン製品全体で共有されて利用されるプラットフォーム機能のほか、Jira 課題サービスや Confluence アナリティクスなどの製品固有の機能が含まれます。
アトラシアンの開発者は、Micros と呼ばれる社内で開発した PaaS (サービスとしてのプラットフォーム) を通じて、これらのサービスをプロビジョニングします。これによって、共有サービス、インフラストラクチャ、データ ストア、セキュリティとコンプライアンス管理の要件を含む管理機能のデプロイが自動で調整されます (上の図 1 参照)。通常、アトラシアン製品は、Micros によって AWS にデプロイされる複数の「コンテナー化」されたサービスで構成されています。アトラシアン製品では、リクエストのルーティングからバイナリ オブジェクト ストア、認証/承認、トランザクションの UGC (ユーザー生成コンテンツ) やエンティティ関係ストア、データ レイク、共通ロギング、リクエスト追跡、監視性、分析サービスに至るまで、コア プラットフォーム機能を使用されています (下の図 2 参照)。
クラウド インフラストラクチャに加えて、アトラシアンは製品をサポートする共有プラットフォームを備えたマルチテナント マイクロサービス アーキテクチャを構築して運用しています。マルチテナント アーキテクチャでは、クラウド製品の運用に必要なデータベースやコンピューティング インスタンスなど、単一のサービスを複数のお客様に提供します。各シャード (基本的にはコンテナー、下の図 3 参照) には複数のテナントのデータが含まれますが、各テナントのデータは分離されていて他のテナントからアクセスできません。アトラシアンではシングル テナント アーキテクチャを提供しておりませんので、ご注意ください。
詳細については、https://www.atlassian.com/trust/reliability/cloud-architecture-and-operational-practices#cloud-infrastructure をご覧ください。 | マルチテナント アーキテクチャ | Atlassian Cloud アーキテクチャと運用プラクティス
データ処理補遺 | Atlassian Trust Center |
| 原則 10: ID と認証 |
| | 認証とアクセス管理の詳細については、9.1 と 9.2 を参照してください。 | なし |
| 原則 11: 外部インターフェイス保護 |
| | Atlassian Trust がクラウドのお客様をどのように保護するかについて詳しくは、原則 5 を参照してください。 | なし |
| 原則 12: 安全なサービス管理 |
| | アトラシアンのデータ処理補遺では、アクセス制御や権限管理など、お客様のデータを保護することを約束しています。
認証とアクセス管理の詳細については、9.1 と 9.2 を参照してください。 | なし |
| 原則 13: ユーザー向けの監査情報 |
| | お客様のアプリケーションへのアクセスはすべて記録されます。ユーザーインターフェイスのすべての操作は、アプリケーション監査ログに記録されます。
アトラシアンでは、Atlassian アカウント ID ストアやその他の情報セキュリティ管理システムへの特権アクセスを制限、記録、監視しています。
ログは論理的に分離されたシステムに保存されて、ログへの書き込みアクセスはセキュリティ チームのメンバーに制限されます。ログから特定のアクションやイベントが識別されると、セキュリティ チームまたはサービス デスクにアラートが送信されます。当社の (Atlassian Cloud Platform、Jira、Confluence、Bamboo を対象として) 一元化されたロギング サービスは、自動分析のためにセキュリティ分析インフラストラクチャと統合されており、潜在的な問題を特定するアラートが作成されます。
Bitbucket では、監査ログはインシデント後の調査に使用されます。Puppet マネージドのサービス構成、および宣言型の構成形式によって、マニフェストの管理対象であるすべてのシステム構成が実行のたびに正しく構成されます。特定のサーバーで Puppet の実行に失敗すると、監視アラートが発行されます。当社の内外の脆弱性スキャナーには、予期しないポートが開いている場合、あるいは他の構成変更 (リスニング サーバーの TLS プロファイルなど) に関する警告が含まれています。
Atlassian Access をご覧ください。詳細については、Atlassian Access | Jira や Confluence のセキュリティと SSO をご覧ください。
アトラシアン内部では、ログは論理的に分離されたシステムに保存されて、ログへの書き込みアクセスはセキュリティ チームおよびオブザーバビリティ チームのメンバーに制限されます。当社の一元化されたロギング サービスはセキュリティ分析インフラストラクチャと統合されており、自動分析が行われ、アラートが作成されて潜在的な問題が特定されます。
Atlassian Cloud のお客様は、組織の変更に関する監査ログを Atlassian Access の一部として利用できます。監査ログを使用すれば、ユーザー、グループ、権限などに対する管理アクションを可視化できます。詳細については、https://support.atlassian.com/security-and-access-policies/docs/track-organization-activities-from-the-audit-log/ をご覧ください。
Atlassian cloud 製品には、製品固有の変更に関する独自の監査ログもあります。 | なし |
| 原則 14: サービスの安全な利用 |
| | アトラシアンでは、これをお客様とアトラシアン両方が共有すべき責任だととらえています。
このガイド内でも触れたように、さまざまなリソースから脆弱性管理やセキュリティ全般に対するアトラシアンのアプローチについて詳細な情報を得られます。
| なし |