ENISA：欧州ネットワーク情報セキュリティ機関
Atlassian アウトソーシング ガイドライン
免責事項
以下のガイダンスは、ヨーロッパのクラウドの顧客、およびビジネス機能のクラウドへのアウトソーシングを検討している企業が、アトラシアンのクラウド製品や関連サービスを評価する際にサポートすることのみを目的としています。
このレポートは、アトラシアンが ENISA IAF にどのように準拠しているかに関して、アトラシアンがクラウド顧客に情報やガイダンスを提供することのみを目的としています。これと並行して、アトラシアンは、アトラシアンなどのクラウド・サービス・プロバイダ（以下「CSP」）とその顧客の双方が、ENISA IAF のコンプライアンスを確保する際に念頭に置く必要がある共同責任について取り上げている専用の共同責任ホワイトペーパーを用意しています。この共同責任モデルでは、Atlassian Cloud 製品を使用するお客様の説明責任とリスクがなくなるわけではありませんが、システム・コンポーネントや施設の物理的制御を管理・制御し、セキュリティとコンプライアンス・コストの一部をアトラシアンに移し、お客様から切り離すなどのさまざまな方法で、お客様の負担を軽減するのに役立ちます。
お客様のデータ保護への取り組みについての詳細は、アトラシアンのセキュリティ プラクティス ページをご覧ください。
| | ID | ENISA ガイダンス | アトラシアンの対応 |
概要 | |||
|
|
| ENISA（欧州ネットワーク情報セキュリティ機関）は、ネットワークと情報の専門知識の中心地です。EU 加盟国や民間企業と緊密に協力して、効果的なサイバーセキュリティの実践に関するアドバイスと推奨事項を提供しています。ENISA はまた、国内の情報セキュリティに関する EU の政策と法の策定と実施を支援しています。 | アトラシアンは、CSA（クラウド・セキュリティ・アライアンス）の CCM（クラウド・コントロール・マトリックス）をアトラシアンが遵守しているという理由から IAF と連携しており、CCM のドメインとコントロールは IAF の保証基準と ISO 27001 の認証にマッピングされています。
次のガイダンスは、組織がクラウド・サービス・プロバイダを選ぶ際の保証基準を示しています。具体的な内容に関する質問がある場合は、エンタープライズ・セールス・チーム（https://www.atlassian.com/ja/enterprise/contact?formType=product-features）にお問い合わせください。 |
IAF（情報セキュリティ確保のためのフレームワーク） | |||
人的セキュリティ | |||
| | 6.01 | 人事に関する質問の大部分は、自社 IT 担当者や IT 関連の他の担当者への質問と類似しています。ほとんどの評価と同様、リスクとコストの間にはバランスがあります。 |
|
| 6.01. (a) | IT 管理者など、システムへのアクセスが可能な人材を雇用するとき、どのようなポリシーや手順を定めているでしょうか？それには以下のものを含める必要があります。
| アトラシアンの新入社員には、居住地の法律に従って身元確認を行うことが求められます。買収の結果として新たに雇用された社員については、居住地の法律に従い、買収日後に身元確認を行います。犯罪歴の確認は、すべての新入社員と独立した請負業者に対して一律に実施されます。役割や役職に必要であれば、学歴検証、職歴検証、与信確認が追加されます。上級管理職や経理職については特に身元確認を徹底しています。 | |
| 6.01. (b) | データの保存場所やアプリケーションの実行場所によってポリシーは異なるでしょうか？
| アトラシアンでは、最小限の権限に基づいて、当社のシステム、アプリケーション、インフラストラクチャへのアクセスを、職務や責任上必要とする人員のみに限定しています。これは当社の認証プロセスによって実施しています。すべてのアクセスは認証されたセッションを介して、確立された権限に基づいて行われます。 | |
| 6.01. (c) | 全スタッフに対して、どのようなセキュリティ教育プログラムを実施していますか？ | アトラシアンでは、オンボーディング・トレーニング（「Day 1」）の一環として新入社員向けに、また全スタッフに対して継続的な情報セキュリティ・トレーニングを提供しています。 | |
| 6.01. (d) | 継続的な評価のプロセスはありますか？
| アトラシアンはそのクラウド・サービスについて SOC2、ISO27001、および ISO27018 の認証を取得しています。当社では少なくとも年に 1 回、社内の準備体制の監査と外部監査の両方を実施しています。アトラシアンは多数の製品で ISO 認証を受けているため、定期的なリスク評価とデータ・プラクティスのレビューが求められます。 | |
サプライチェーン保証 | |||
| | 6.02. | 次の質問は、クラウド・プロバイダが運用のセキュリティに重要な操作をサードパーティに外注する場合（たとえば、SaaS プロバイダが基盤となるプラットフォームをサードパーティ・プロバイダにアウトソーシングする、クラウド・プロバイダがセキュリティ・サービスをマネージド・セキュリティ・サービス・プロバイダにアウトソーシングする、オペレーティング・システムの ID 管理に外部プロバイダを使用するなど）に該当します。これにはクラウド・プロバイダのインフラストラクチャに物理的またはリモートでアクセスできるサードパーティも含まれます。このアンケート全体は、サードパーティ（またはその他）のクラウド・サービス・プロバイダに再帰的に適用されることを前提としています。 |
|
| 6.02. (a) | 業務のセキュリティ（可用性を含む）にとって重要な、サービス提供サプライ・チェーンにおいてアウトソーシングまたは下請けされるサービスを定義します。 | アトラシアンはサードパーティの下請業者と協力し、Web サイト、アプリ開発、ホスティング、メンテナンス、バックアップ、ストレージ、仮想インフラストラクチャ、支払い処理、分析、その他のサービスを提供しています。アトラシアンが現在契約し、顧客が承認した復処理者のリストは、https://www.atlassian.com/ja/legal/sub-processors に掲載されています。 | |
| 6.02. (b) | サードパーティがお客様のインフラストラクチャに（物理的にまたは論理的に）確実にアクセスするための手順について詳しく説明します。
| 当社の法務チームと調達チームは、契約、SLA、およびベンダー内部ポリシーを確認して、セキュリティ、可用性、機密保持に関連するリスクを管理します。また、リスク・プロファイルに基づき、必要に応じて機能的リスク評価を実施します。リスク評価はポリシー更新の一環として、またサプライヤーとの関係が大きく変わるたびに再検討されます。アトラシアンのサプライヤーおよびサードパーティのデータ管理ポリシーではこのプロセスを網羅しており、その抜粋については https://www.atlassian.com/ja/trust/security/ismp-policies をご覧ください。 | |
| 6.02. (c) | アウトソーシングした業者によって保証されている SLA 条項に、お客様が顧客に提供する SLA を下回っているものはありますか？それがない場合、サプライヤーの冗長性を確保していますか？ | ライセンスの取り決めに応じて、顧客のクラウド利用規約を月間サブスクリプションまたは年間サブスクリプションの更新のいずれかで確認する必要があります。当社の法務チームと調達チームは、契約、SLA、およびベンダー内部ポリシーを確認して、セキュリティ、可用性、機密保持に関連するリスクを管理します。アトラシアンの ERM (エンタープライズ リスク管理) プログラムでは、すべてのリスク カテゴリに関する可能性と影響が組み込まれ、COSO リスク モデルに沿ったリスク評価を年に 1 回実施しています。また、リスク プロファイルに基づき、必要に応じて機能的リスク評価を実施します。リスク評価はポリシー更新の一環として、またサプライヤーとの関係が大きく変わるたびに再検討されます。 | |
| 6.02. (d) | サードパーティ・サービス・レベルを達成し、維持するためにどのような対策がとられていますか？ | 当社の法務チームと調達チームは、契約、SLA、およびベンダー内部ポリシーを確認して、セキュリティ、可用性、機密保持に関連するリスクを管理します。また、リスク・プロファイルに基づき、必要に応じて機能的リスク評価を実施します。リスク評価はポリシー更新の一環として、またサプライヤーとの関係が大きく変わるたびに再検討されます。アトラシアンのサプライヤーおよびサードパーティのデータ管理ポリシーではこのプロセスを網羅しており、その抜粋については https://www.atlassian.com/ja/trust/security/ismp-policies をご覧ください。 | |
| 6.02. (e) | クラウド・プロバイダは、セキュリティ・ポリシーとその管理が（契約上）サードパーティ・プロバイダに適用されていることを確認できますか？ | すべてのシステムとプロジェクトは PII に関連しているため、影響評価の対象になります。アトラシアンのサードパーティ契約には、適用されるセキュリティとプライバシーの規定が含まれています。アトラシアンの新規ベンダーは、契約にあるプライバシーおよびセキュリティ・ポリシーに同意する必要があります。 | |
運用上のセキュリティ | |||
| | 6.03. | 外部プロバイダとの商業契約には、すべてのネットワーク・サービスに対するサービス・レベルが含まれることが想定されます。しかし、明確な契約に加え、エンド・カスタマーは、プロバイダが不正な開示を防止するために適切な管理体制をとっていることを確認する必要があります。 |
|
| | 6.03. (a) | 変更管理の手順とポリシーについて詳しく説明してください。変更の結果としてのリスクを再評価し、その成果がエンド・カスタマーに提示されるかどうかを明確にするため、使用するプロセスもこれに含める必要があります。 | アトラシアンには、COSO リスク・モデルと ISO 31000 に沿った ERM（エンタープライズ・リスク管理）プログラムがあります。ERM プログラムでは、アトラシアン全体でリスク管理の枠組みと手法を導入し、製品環境の年次リスク評価と定期的な特定リスク評価、および機能リスク評価を適宜、リスク・プロファイルに基づいて実施します。 |
| | 6.03. (b) | リモート・アクセス・ポリシーを定義します。 | リモート・アクセスの要件は、アクセス管理ポリシーと関連する標準で定義されています。有効なカスタマー・サポート・チケットがあれば、サポートや移行の目的のために顧客データを従業員のワークステーションに複製できます。厳格なファイアウォール・ルールが設けられているため、本番環境へのアクセスはアトラシアンの VPN ネットワークと許可されたシステムに制限されています。この VPN アクセスには多要素認証が求められます。 |
| | 6.03. (c) | プロバイダは、情報システムの運用手順を文書化していますか？ | アトラシアンの運用セキュリティの基本原則には、標準の運用手順の文書化が含まれています。また、それぞれの高度なポリシーとその詳細については、https://www.atlassian.com/ja/trust/security/ismp-policies#policy-risk-governance で抜粋しています。 |
| | 6.03. (d) | 開発環境、テスト環境、運用環境など、リスクを軽減するための段階的な環境がありますか？また、それらは分けられていますか？ | アトラシアンには、非本番環境での本番データの使用を禁止する情報セキュリティ・ポリシーがあり、環境間でデータを移行しようとすると、変更管理プロセスによって特定されます。コードはまず、ユニット・テストによって一元化されたビルド・システムから移動されます。次に、追加のテストの自動化、および PM、開発、QA によるゲート・レビューによって機能ブランチの検証に進みます。その後、UAT、セキュリティ、パフォーマンスの検証を実施します。開発者がコードを本番環境に直接昇格させることはできません。詳細については、https://www.atlassian.com/ja/trust/security/security-practices#managing-changes-in-our-environment をご覧ください。 |
| | 6.03. (e) | エンド・カスタマーのアプリケーションと情報をホスティングするシステムを保護するためのホストとネットワークのコントロールを定義します。これには外部規格（ISO 27001/2 など）に対する認証の詳細を含めます。 | アトラシアンのネットワーク・エンジニアリングは、クラウドとオフィスのファイアウォールに組み込まれた IPS テクノロジーを使用しており、オフィス環境には IDS テクノロジーを実装しています。ネットワーク脅威対策は、DDoS 保護や一部の Web アプリケーション・ファイアウォール機能を含め、AWS によって実施されています。当社のサービスのデータはすべて、不正な開示や変更を防止するため、HTTPS か SMTPS かを問わず、TLS を使用して転送中に暗号化されます。 |
| | 6.03. (f) | 悪意のあるコードからの保護に使用するコントロールを指定します。 | アトラシアンは Crowdstrike Falcon（https://www.crowdstrike.com/falcon-platform/）を Windows PC と Mac に実装しています。Linux マシンではマルウェア対策を実施していません。マルウェア対策は、アトラシアンの脆弱性管理ポリシーに組み込まれています。 |
|
| 6.03. (g) | 承認されたモバイル・コードと機能の実行のみ（特定のコマンドのみを実行するなど）を許可するようにセキュリティ保護された構成がデプロイされていますか？ | すべてのサーバーは、一元化された Puppet 構成システムを使用して、既定のイメージから一部のパッケージを削除したり、重要なパッケージを更新したりするなど、標準の運用環境に合わせて構成されています。すべてのサーバー・ロールは、受信するネットワーク・リクエストすべてをデフォルトで拒否し、特定のポートへのアクセス権のあるサーバー・ロールに対してのみそのポートが開かれ、機能します。 |
|
| 6.03. (h) | バックアップに関するポリシーと手順について説明します。ここではリムーバブル・メディアの管理手順と、不要になったメディアを安全に破棄する方法についても取り上げます。（ビジネス要件によっては、お客様は個別のバックアップ戦略の導入を希望されるかもしれません。バックアップへのアクセスに時間制限がある場合には特に重要です） | アトラシアンでは、包括的なバックアップ・プログラムを運用しています。これには、システム・リカバリ要件に合わせてバックアップ対策が設計されている社内システムも含まれます。アトラシアンのクラウド製品の、特にお客様とそのアプリケーションのデータについては、広範なバックアップ対策も講じています。Amazon RDS（Relational Database Service）のスナップショット機能によって、RDS インスタンスごとの自動バックアップを毎日作成しています。Amazon RDS スナップショットは、ポイントインタイム・リカバリ（特定時点への復元）をサポートできるよう 30 日間保持され、AES-256 暗号化を使用して暗号化されます。バックアップ・データはオフサイトに保存されませんが、特定の AWS リージョン内にある複数のデータ・センターにレプリケーションされます。また、四半期ごとにバックアップ・テストを実施しています。Bitbucket では、データは異なる AWS リージョンにレプリケーションされ、各リージョン内で毎日独立したバックアップが作成されます。 |
|
|
| 監査ログは、調査が必要なインシデントが発生した場合やトラブルシューティングに使用されます。この目的のために、最終顧客にそのような情報が提供されることを保証する必要があります。 |
|
|
| 6.03. (i) | 監査ログに記録されている情報については、プロバイダからを詳しく説明されますか？
| ログが読み取り専用となっている各システムから、重要なシステム・ログが中央のログ記録用プラットフォームに転送されます。アトラシアン・セキュリティ・チームでは、セキュリティ分析プラットフォーム（Splunk）上でアラートを作成し、セキュリティ侵害の兆候を監視します。SRE チームでは、このプラットフォームを使用して、可用性またはパフォーマンスの課題を監視します。ログは、ホット・バックアップで 30 日間、コールド・バックアップで 365 日間保持されます。 |
|
| 6.03. (j) | 監査ログはどのように確認されますか？記録されたイベントに対してどのような措置がとられますか？ | ログが読み取り専用となっている各システムから、重要なシステム・ログが中央のログ記録用プラットフォームに転送されます。アトラシアン・セキュリティ・チームでは、セキュリティ分析プラットフォーム（Splunk）上でアラートを作成し、セキュリティ侵害の兆候を監視します。SRE チームでは、このプラットフォームを使用して、可用性またはパフォーマンスの課題を監視します。ログは、ホット・バックアップで 30 日間、コールド・バックアップで 365 日間保持されます。 |
|
| 6.03. (k) | システムを同期し、正確な監査ログのタイム・スタンプを提供するには、どの時間ソースが使われますか？ | Atlassian Cloud では、デプロイされているすべてのインスタンスに AWS Time Sync を利用しています。 |
ソフトウェア保証 | |||
|
| 6.03.01. (a) | 使用するオペレーティング・システムとアプリケーション・ソフトウェアの整合性を保護するためのコントロールを定義します。OWASP、SANS チェックリスト、SAFECode など、準拠する基準をすべて含めます。 | 当社のセキュリティ・エンジニア・チームは開発サイクルの一環として、製品のすべてのソース・コードについて継続的にローリング・レビューを実施します。これには自動と手作業の両方の手法を採用しています。また、複数の上級開発者または主任開発者がすべてのコミットをレビューして master にする二重のピア・レビュー・プロセスも必須として利用しています。アジャイル・ワークフローにより、特にクラウド・サービスについては脆弱性を迅速に特定し、修正しています。 |
|
| 6.03.01. (b) | 新しいリリースは目的に沿ったものかどうか、またリスク（バックドア、トロイの木馬など）がないかをどのように検証しますか？それは使用前に確認されていますか？ | アトラシアンの変更管理プロセスは、従来の変更プロセスとは少し異なります。コード、アプリ、インフラストラクチャの変更など、すべての変更について PRGB（ピア・レビュー、グリーン・ビルド）の管理に依存しています。ピア・レビューはアトラシアンの CD ツールで設定され、重要なブランチについては、プル・リクエストごとに複数のレビュー担当者を指定します。通常、これは 2 人の開発者とチーム・リーダーです。コントロールのグリーン・ビルド部分は、CI フェーズでの統合が、これまでに開発されたすべての統合、機能、セキュリティ、およびその他のテストで合格する必要があることを示します。これらのテストが失敗（レッド・ビルド）した場合、コードはマージされないため、もう一度レビューして障害に対処する必要があります。グリーン・ビルドが完了すると、バイナリが暗号により署名され、本番環境ではアトラシアンのキーで署名されたバイナリだけが実行されます。アトラシアンのテスト・プロセスには、自動評価と手動評価の両方のコンポーネントが含まれています。アトラシアンでは、進行中のものについてブログで報告しています。アトラシアンは現在、従来の「品質保証（Quality Assurance）」ではなく https://www.atlassian.com/ja/inside-atlassian/quality-assurance-vs-quality-assistance の「品質支援（Quality Assistance）」を利用するアプローチに注目しています。 |
|
| 6.03.01. (c) | アプリケーションを安全に保つため、どのような方法がとられていますか？ | アトラシアンのアプリケーションでは PRGB（ピア・レビューとグリーン・ビルド）が求められます。その後はアプリケーションのアーティファクトが暗号により署名され、CI/CD パイプラインによって自動的にデプロイされ、アトラシアンが署名したアプリケーションのみ本番環境で実行可能になります。 |
|
| 6.03.01. (d) | ソフトウェア・リリースのペネトレーション・テストでは脆弱性がないかどうかを確認していますか？脆弱性が発見された場合、それを修正するプロセスはどのようなものですか？ | アトラシアンは開発ライフサイクルのすべてのフェーズで、安全な開発を実践しています。詳細については、https://www.atlassian.com/ja/trust/security/security-in-development をご覧ください。 |
パッチ管理 |
|
|
|
|
| 6.03.02. (a) | 利用しているパッチ管理の手順について詳細を説明してください。 | アトラシアンでは、脅威と脆弱性の管理ポリシーを保持しています。アトラシアンの PMP（ポリシー管理プログラム）には、オーナーシップ、可用性、レビュー・サイクルに関する定義とアトラシアンの全般的な目標が記載されています。ポリシーは少なくとも年に 1 回見直され、経営幹部の承認を受けます。PMP の詳細については、https://www.atlassian.com/ja/trust/security/security-management-program をご覧ください。 |
|
| 6.03.02. (b) | パッチ管理プロセスは、クラウド・デリバリー・テクノロジーのすべての層、つまりネットワーク（インフラストラクチャ・コンポーネント、ルーター、スイッチなど）、サーバー・オペレーティング・システム、仮想化ソフトウェア、アプリケーション、セキュリティ・サブシステム（ファイアウォール、ウイルス対策ゲートウェイ、侵入検知システムなど）を対象としていますか？ | システム構成の変更は、本稼働へのデプロイの前のすべての変更のレビューを含めた自動プロセスによって管理されます。アトラシアンのサービス・オペレーションは、重大なリスクが特定され次第、パッチをデプロイできます。アトラシアンには、パッチをどれだけ迅速に実装すべきかを判断する内部基準があり、すべてのマシンに対して 12 時間以内の適用が可能です。システム構成ファイルの監視を含む IDS システムが導入されています。 |
ネットワーク・アーキテクチャ制御 | |||
|
| 6.03.03. (a) | DDoS（分散 DoS）攻撃を軽減するための制御を定義します。
| ネットワーク・セキュリティ要件は、通信セキュリティ・ポリシーで定義されています。このポリシーは PMP（ポリシー管理プログラム）に沿って毎年レビューされます。PMP の詳細については、https://www.atlassian.com/ja/trust/security/security-management-program をご覧ください。 |
|
| 6.03.03. (b) | どのレベルの隔離が使われていますか？
| アトラシアンはマルチテナント型の SaaS アプリです。マルチテナントは Atlassian Cloud の重要な機能であり、それぞれの顧客テナントのアプリケーション・データを分離しながら、複数の顧客が Jira または Confluence アプリケーション・レイヤーの 1 つのインスタンスを共有できるようにします。Atlassian Cloud では TCS（テナント・コンテキスト・サービス）によってこれを実現しています。すべてのユーザー ID はそれぞれテナント 1 つだけに関連付けられ、それが Atlassian Cloud アプリケーションへのアクセスに使用されます。詳細については、https://www.atlassian.com/ja/trust/security/security-practices#tenant-isolation をご覧ください。 |
|
| 6.03.03. (c) | このアーキテクチャは、企業がサービス・プロバイダから分離されている場合でも、またその逆の場合でも、クラウドからの継続的な運用をサポートしている（たとえば、顧客の LDAP システムに大きく依存している）でしょうか？ | ビジネス継続性とディザスタ・リカバリに関するポリシー、およびその計画が策定されており、ビジネス継続性/ディザスタ・リカバリ運営委員会によって毎年レビューされています。詳細については、https://www.atlassian.com/ja/trust/security/security-practices#managing-access-to-systems-and-services と https://www.atlassian.com/ja/trust/security/data-management をご覧ください。 |
|
| 6.03.03. (d) | クラウド・プロバイダが使用する仮想ネットワーク・インフラストラクチャ（PVLAN および VLAN タグ 802.1q アーキテクチャ）は、ベンダーやベスト・プラクティス固有の標準で保護されているでしょうか（たとえば、MAC スプーフィング、ARP ポイズニング攻撃などが特定のセキュリティ構成によって防止されているでしょうか）？ | ネットワーク・セキュリティ要件は、通信セキュリティ・ポリシーで定義されています。このポリシーは PMP（ポリシー管理プログラム）に沿って毎年レビューされます。PMP の詳細については、https://www.atlassian.com/ja/trust/security/security-management-program をご覧ください。 |
ホスト・アーキテクチャ | |||
|
| 6.03.04. (a) | プロバイダは仮想イメージが既定で強化されていることを保証していますか？ | すべてのサーバーは、一元化された Puppet 構成システムを使用して、既定のイメージから一部のパッケージを削除したり、重要なパッケージを更新したりするなど、標準の運用環境に合わせて構成されています。すべてのサーバー・ロールは、受信するネットワーク・リクエストすべてをデフォルトで拒否し、特定のポートへのアクセス権のあるサーバー・ロールに対してのみそのポートが開かれ、機能します。 |
|
| 6.03.04. (b) | 強化された仮想イメージは不正アクセスから保護されますか？ | すべてのサーバーは、一元化された Puppet 構成システムを使用して、既定のイメージから一部のパッケージを削除したり、重要なパッケージを更新したりするなど、標準の運用環境に合わせて構成されています。すべてのサーバー・ロールは、受信するネットワーク・リクエストすべてをデフォルトで拒否し、特定のポートへのアクセス権のあるサーバー・ロールに対してのみそのポートが開かれ、機能します。 |
|
| 6.03.04. (c) | プロバイダは、仮想化されたイメージに認証の資格情報が含まれていないことを確認できますか？ | すべてのサーバーは、一元化された Puppet 構成システムを使用して、既定のイメージから一部のパッケージを削除したり、重要なパッケージを更新したりするなど、標準の運用環境に合わせて構成されています。すべてのサーバー・ロールは、受信するネットワーク・リクエストすべてをデフォルトで拒否し、特定のポートへのアクセス権のあるサーバー・ロールに対してのみそのポートが開かれ、機能します。 |
|
| 6.03.04. (d) | ホストのファイアウォールは、仮想インスタンス内のサービスのサポートに必要とされる最小限のポートだけで動作しているのでしょうか？ | すべてのサーバーは、一元化された Puppet 構成システムを使用して、既定のイメージから一部のパッケージを削除したり、重要なパッケージを更新したりするなど、標準の運用環境に合わせて構成されています。すべてのサーバー・ロールは、受信するネットワーク・リクエストすべてをデフォルトで拒否し、特定のポートへのアクセス権のあるサーバー・ロールに対してのみそのポートが開かれ、機能します。 |
|
| 6.03.04. (e) | ホストベースの IPS（侵入防止サービス）は仮想インスタンスで実行できるでしょうか？ | アトラシアンは SaaS（サービスとしてのソフトウェア）モデルを運用しているため、これには該当しません。 |
PaaS - アプリケーション・セキュリティ | |||
|
| 6.03.05. | 一般的に、PaaS サービス・プロバイダはプラットフォーム・ソフトウェア・スタックのセキュリティについて責任を負います。そのため、このドキュメント全体に記載されている推奨事項は、PaaS プロバイダが PaaS プラットフォームを設計および管理する際に、セキュリティ原則を考慮したかどうかを確認するための基盤として使用することができます。PaaS プロバイダから、プラットフォームの保護方法に関する詳細情報を得ることは簡単ではありませんが、以下の質問とこのドキュメントの他のセクションを使用すれば、PaaS プロバイダが提供するサービスを評価できるでしょう。 |
|
|
| 6.03.05. (a) | マルチテナント・アプリケーションがそれぞれどのように分離されているかについて、情報をリクエストします。封じ込めと分離の対策について、大まかな説明が必要です。 | アトラシアンは SaaS（サービスとしてのソフトウェア）モデルを運用しているため、これには該当しません。 |
|
| 6.03.05. (b) | PaaS プロバイダは、データへのアクセスがエンタープライズ・ユーザーと所有するアプリケーションに限定されていることをどう保証しているでしょうか？ | アトラシアンは SaaS（サービスとしてのソフトウェア）モデルを運用しているため、これには該当しません。 |
|
| 6.03.05. (c) | プラットフォーム・アーキテクチャは従来の「サンドボックス」であるべきです。プロバイダでは、PaaS プラットフォームのサンドボックスに新たなバグや脆弱性がないか監視されているのでしょうか？ | アトラシアンは SaaS（サービスとしてのソフトウェア）モデルを運用しているため、これには該当しません。 |
|
| 6.03.05. (d) | PaaS プロバイダは、一連のセキュリティ機能（クライアント間で再使用可能）を提供できますが、これにはユーザー認証、シングル・サインオン、承認（権限管理）、SSL/TLS（API により利用可能）は含まれますか？ | アトラシアンは SaaS（サービスとしてのソフトウェア）モデルを運用しているため、これには該当しません。 |
SaaS：アプリケーション・セキュリティ | |||
|
| 6.03.06. | SaaS モデルでは、プロバイダがエンドユーザーに提供されるアプリケーション・スイート全体を管理すると規定されています。したがって、SaaS プロバイダは主にこれらのアプリケーションを保護する責任を負います。通常、運用上のセキュリティ・プロセス（ユーザーおよびアクセスの管理）についてはお客様が責任を負います。ただし、その内容を評価する場合は、次の質問、およびこのドキュメント内の他のセクションを利用できます。 |
|
|
| 6.03.06. (a) | どのような管理権限があり、それをどのように使用して読み取り権限や書き込み権限を他のユーザーに割り当てることができますか？ | アトラシアンの Enterprise および Premium Cloud サービスのお客様は、一元化された管理コントロール・パネルにアクセスできます。組織の管理者であれば、すべての製品インスタンスのユーザー・アクセスと権限を管理できます。こちらのブログ投稿をご覧ください：https://www.atlassian.com/blog/platform/cloud-enterprise-centralized-admin-controls |
|
| 6.03.06. (b) | SaaS アクセス制御は、組織のポリシーに合わせてきめ細かくカスタマイズできますか？ | アトラシアンの Enterprise および Premium Cloud サービスのお客様は、一元化された管理コントロール・パネルにアクセスできます。組織の管理者であれば、すべての製品インスタンスのユーザー・アクセスと権限を管理できます。こちらのブログ投稿をご覧ください：https://www.atlassian.com/blog/platform/cloud-enterprise-centralized-admin-controls |
リソース・プロビジョニング | |||
|
| 6.03.07. (a) | リソースの過負荷（処理、メモリ、ストレージ、ネットワーク）が発生した場合：
| アトラシアンでは、キャパシティについては 6 か月から 12 か月前に計画し、高度な戦略的計画については 36 か月後に通知されます。 |
|
| 6.03.07. (b) | どれくらいスケールアップできますか？プロバイダは、利用可能な最大リソースの最短期間での提供を保証していますか？ | アトラシアンでは、キャパシティについては 6 か月から 12 か月前に計画し、高度な戦略的計画については 36 か月後に通知されます。 |
|
| 6.03.07. (c) | どれくらいのスピードでスケールアップできますか？プロバイダは、リソースの最短期間での補充を保証していますか？ | アトラシアンでは、キャパシティについては 6 か月から 12 か月前に計画し、高度な戦略的計画については 36 か月後に通知されます。 |
|
| 6.03.07. (d) | リソース使用量の大規模な傾向（季節的な影響など）に対処するには、どのようなプロセスがありますか？ | アトラシアンでは、キャパシティについては 6 か月から 12 か月前に計画し、高度な戦略的計画については 36 か月後に通知されます。 |
ID とアクセス管理 | |||
認証 | |||
|
| 6.04.01. | クラウド・プロバイダの ID およびアクセス管理システム（制御対象のもの）には、次の制御が適用されます。 |
|
|
| 6.04.01. (a) | クラウド・システム全体について、システム全体におよぶ権限を持つアカウントはありますか？ある場合、どのような操作（読み取り/書き込み/削除）が可能ですか？ | 当社のグローバル・サポート・チームは、保守とサポートのために、ホストされているすべてのシステムとアプリケーションのアカウントを管理しています。当社サポート・チームは、アプリケーションの正常性の監視、システムまたはアプリケーションの保守、または当社のサポート・システム経由でのお客様からの依頼に基づき、ホストされているアプリケーションやデータにアクセスしています。 |
|
| 6.04.01. (b) | 最高レベルの権限を持つアカウントはどのように認証され、管理されますか？ | アトラシアンは、このアクセスを職務や責任上、必要とする人員のみに限定しています。第 1 層のシステムはすべて、アトラシアンで一元化された SSO（シングル・サインオン）とディレクトリ・ソリューションで管理されています。ユーザーには、当社の人事管理システムからのワークフローを介して、これらのプロファイルに基づく適切なアクセス権が付与されます。アトラシアンは MFA を利用して第 1 層システムのすべてにアクセスしています。ハイパーバイザー管理コンソールと AWS API への 2 要素認証と、ハイパーバイザー管理機能へのすべてのアクセスに関する毎日の監査レポートを有効にしています。ハイパーバイザー管理コンソールと AWS API へのアクセス・リストは四半期ごとに見直されます。また、人事システムと ID ストアの間で 8 時間ごとの同期を維持しています。 |
|
| 6.04.01. (c) | 最も重要な意思決定（大規模なリソース・ブロックの同時プロビジョニング解除など）はどのように承認されますか（シングル・サインオンか 2 要素認証か、組織内のどのロールを使用するか）？ | アトラシアンは、このアクセスを職務や責任上、必要とする人員のみに限定しています。第 1 層のシステムはすべて、アトラシアンで一元化された SSO（シングル・サインオン）とディレクトリ・ソリューションで管理されています。ユーザーには、当社の人事管理システムからのワークフローを介して、これらのプロファイルに基づく適切なアクセス権が付与されます。アトラシアンは MFA を利用して第 1 層システムのすべてにアクセスしています。ハイパーバイザー管理コンソールと AWS API への 2 要素認証と、ハイパーバイザー管理機能へのすべてのアクセスに関する毎日の監査レポートを有効にしています。ハイパーバイザー管理コンソールと AWS API へのアクセス・リストは四半期ごとに見直されます。また、人事システムと ID ストアの間で 8 時間ごとの同期を維持しています。
|
|
| 6.04.01. (d) | 同一人物に権限の高いロールが複数割り当てられていませんか？その割り当ては職務分掌や最小特権のルールに反していませんか？ | アトラシアンは、このアクセスを職務や責任上、必要とする人員のみに限定しています。第 1 層のシステムはすべて、アトラシアンで一元化された SSO（シングル・サインオン）とディレクトリ・ソリューションで管理されています。ユーザーには、当社の人事管理システムからのワークフローを介して、これらのプロファイルに基づく適切なアクセス権が付与されます。アトラシアンは MFA を利用して第 1 層システムのすべてにアクセスしています。ハイパーバイザー管理コンソールと AWS API への 2 要素認証と、ハイパーバイザー管理機能へのすべてのアクセスに関する毎日の監査レポートを有効にしています。ハイパーバイザー管理コンソールと AWS API へのアクセス・リストは四半期ごとに見直されます。また、人事システムと ID ストアの間で 8 時間ごとの同期を維持しています。
|
|
| 6.04.01. (e) | RBAC（ロールベースのアクセス制御）を利用していますか？最小特権の原則に従っていますか？ | アトラシアンでは、確立されたワークフローで、当社の人事管理システムとアクセス・プロビジョニング・システムを連携しています。事前定義済みのユーザー・プロファイルに基づき、ロールベースのアクセス制御を使用しています。すべてのユーザー・アカウントは、データ、アプリケーション、インフラストラクチャ、またはネットワーク・コンポーネントにアクセスする前に、管理者の承認を得る必要があります。 |
|
| 6.04.01. (f) | 緊急時の特別アクセスを許可するために管理者権限とロールに変更が加えられている場合、それはどのようなものですか？ | 当社のグローバル・サポート・チームは、保守とサポートのために、ホストされているすべてのシステムとアプリケーションのアカウントを管理しています。当社サポート・チームは、アプリケーションの正常性の監視、システムまたはアプリケーションの保守、または当社のサポート・システム経由でのお客様からの依頼に基づき、ホストされているアプリケーションやデータにアクセスしています。 |
|
| 6.04.01. (g) | お客様に「管理者」のロールはありますか？たとえば、お客様の管理者に新しいユーザーを追加するロール（ただし、その基盤となるストレージは変更できない）はありますか？ | アトラシアンは、お客様が使用する製品のユーザーとグループを管理する「組織管理者」のロールをお客様に提供しています。詳細については、https://support.atlassian.com/ja/user-management/docs/give-users-admin-permissions/ をご覧ください。 |
ID プロビジョニング | |||
|
| 6.04.02. (a) | ユーザー・アカウント ID の登録時には、どのようなチェックが行われますか？どのような基準に沿っていますか？電子政府相互運用性フレームワークなどですか？
| 世界各国で、アトラシアンの新入社員には、身元確認を行うことが求められます。買収によって新たに雇用された社員については、買収後に身元確認が行われます。犯罪歴の確認は、すべての新入社員と独立した請負業者に対して一律に実施されます。ロールや役職に必要であれば、学歴検証、職歴検証、与信確認が追加されます。上級管理職や経理職については特に身元確認を徹底しています。 |
|
| 6.04.02. (b) | 認証情報のプロビジョニング解除には、どのようなプロセスがありますか？ | 現在、当社のプロビジョニング解除プロセスには、雇用、契約、または合意の終了が含まれています。社内での異動対象のユーザーは通常、エンゲージメントとサポートの継続のために、アクセス権をそのまま保持しています。アトラシアンはその価値観に従って迅速かつ柔軟に対応する顧客中心のチームを維持するために、応答を鈍らせる可能性のあるアクセスを制限するより、アクセスの不正使用を検出することに重点を置いています。 |
|
| 6.04.02. (c) | 認証情報はクラウド・システム全体で同時プロビジョニングおよびプロビジョニング解除されるのでしょうか、あるいは、地理的に分散した複数の場所でのプロビジョニング解除にはリスクがありますか？ | アトラシアンでは、確立されたワークフローで、当社の人事管理システムとアクセス・プロビジョニング・システムを連携しています。事前定義済みのユーザー・プロファイルに基づき、ロールベースのアクセス制御を使用しています。すべてのユーザー・アカウントは、データ、アプリケーション、インフラストラクチャ、またはネットワーク・コンポーネントにアクセスする前に、管理者の承認を得る必要があります。 |
個人データの管理 | |||
|
| 6.04.03. (a) | ユーザー・ディレクトリ（AD、LDAP など）とそれに対するアクセスには、どのようなデータ・ストレージと保護のコントロールが適用されますか？ | データは、アトラシアンの情報のライフサイクルおよびデータ・セキュリティ・ポリシーに従って分類、処理され、それに基づいて制御されます。詳細については、https://www.atlassian.com/ja/trust/security/security-practices をご覧ください。 |
|
| 6.04.03. (b) | ユーザー・ディレクトリのデータは相互運用可能な形式でエクスポートできますか？ | 管理者は管理者パネルからユーザーのディレクトリをエクスポートできます。ガイドについては、アトラシアンのサポート・サイトをご覧ください：https://support.atlassian.com/ja/organization-administration/docs/export-users-from-a-site/ |
|
| 6.04.03. (c) | クラウド・プロバイダ内の顧客データへのアクセスは、知る必要のある人だけに限定されていますか？ | アトラシアンは、このアクセスを職務や責任上、必要とする人員のみに限定しています。第 1 層のシステムはすべて、アトラシアンで一元化された SSO（シングル・サインオン）とディレクトリ・ソリューションで管理されています。ユーザーには、当社の人事管理システムからのワークフローを介して、これらのプロファイルに基づく適切なアクセス権が付与されます。アトラシアンは MFA を利用して第 1 層システムのすべてにアクセスしています。ハイパーバイザー管理コンソールと AWS API への 2 要素認証と、ハイパーバイザー管理機能へのすべてのアクセスに関する毎日の監査レポートを有効にしています。ハイパーバイザー管理コンソールと AWS API へのアクセス・リストは四半期ごとに見直されます。また、人事システムと ID ストアの間で 8 時間ごとの同期を維持しています。
|
キー管理 | |||
|
| 6.04.04. | クラウド・プロバイダの管理下にあるキーの場合： |
|
|
| 6.04.04. (a) | そのキーの読み取り/書き込みのためのセキュリティ制御は整っていますか？たとえば、強力なパスワード・ポリシー、別のシステムへのキーの保存、ルート証明書キーのための HSM（ハードウェア・セキュリティ・モジュール）、スマート・カード・ベースの認証、ストレージへの直接シールド・アクセス、短時間のキー有効期間などです。 | アトラシアンには、暗号技術と暗号化ポリシー、および実装ガイドラインがあります。このポリシーは、PMP（ポリシー管理プログラム）に従って毎年見直され、更新されています。PMP の詳細については、https://www.atlassian.com/ja/trust/security/security-management-program をご覧ください。 |
|
| 6.04.04. (b) | データの署名と暗号化のため、これらの鍵を使用するセキュリティ制御を実施していますか？ | アトラシアンでは、Cloud インフラストラクチャのキー管理手順を文書化しています。S3 に保存されている Amazon 添付ファイルの暗号化キーは、Amazon KMS によって管理されています。暗号化、キー管理、および復号化のプロセスは、既存の監査プロセスの一環として、Amazon によって定期的に内部で検査および検証されています。KMS 内のマスター・キーは作成時に自動ローテーションが有効になり、365 日ごと（年ごと）にマスター・キー・マテリアルが生成されます。 |
|
| 6.04.04. (c) | 重大なセキュリティ侵害が発生した場合の手順、たとえば、キー取り消しリストなどは整っていますか？ | アトラシアンでは、Cloud インフラストラクチャのキー管理手順を文書化しています。S3 に保存されている Amazon 添付ファイルの暗号化キーは、Amazon KMS によって管理されています。暗号化、キー管理、および復号化のプロセスは、既存の監査プロセスの一環として、Amazon によって定期的に内部で検査および検証されています。アトラシアンが管理するキーは、関連するロールや雇用状態の変更に応じてローテーションされます。AWS KMS サービスは、SOC 1、SOC 2、SOC 3 に準拠しています。詳細については、https://aws.amazon.com/kms/ をご覧ください。 |
|
| 6.04.04. (c) | 重大なセキュリティ侵害が発生した場合の手順、たとえば、キー取り消しリストなどは整っていますか？ | アトラシアンでは、Cloud インフラストラクチャのキー管理手順を文書化しています。S3 に保存されている Amazon 添付ファイルの暗号化キーは、Amazon KMS によって管理されています。暗号化、キー管理、および復号化のプロセスは、既存の監査プロセスの一環として、Amazon によって定期的に内部で検査および検証されています。アトラシアンが管理するキーは、関連するロールや雇用状態の変更に応じてローテーションされます。AWS KMS サービスは、SOC 1、SOC 2、SOC 3 に準拠しています。詳細については、https://aws.amazon.com/kms/ をご覧ください。 |
|
| 6.04.04. (d) | キー取り消しは、複数サイトで同時に発生する課題に対処できますか？ | アトラシアンでは、Cloud インフラストラクチャのキー管理手順を文書化しています。S3 に保存されている Amazon 添付ファイルの暗号化キーは、Amazon KMS によって管理されています。暗号化、キー管理、および復号化のプロセスは、既存の監査プロセスの一環として、Amazon によって定期的に内部で検査および検証されています。アトラシアンが管理するキーは、関連するロールや雇用状態の変更に応じてローテーションされます。AWS KMS サービスは、SOC 1、SOC 2、SOC 3 に準拠しています。詳細については、https://aws.amazon.com/kms/ をご覧ください。 |
|
| 6.04.04. (e) | お客様のシステム・イメージは保護または暗号化されていますか？ | アトラシアンは、業界標準の TLS（Transport Layer Security）バージョン 1.2 を使用して、高度暗号化標準 256 ビット（AES）暗号化による安全な接続を確立しています。ユーザー・データを保存するサーバーでは、業界標準のフル・ディスク AES 暗号化を採用します。テナント・データは AWS RDS または RDS バックアップ内で暗号化され、すべての添付ファイルと同様に長期ストレージ（S3）でも暗号化されます。詳細については、https://www.atlassian.com/ja/trust/security/security-practices#encryption-and-key-management をご覧ください。 |
暗号化 | |||
| | 6.04.05. (a) | 暗号化はさまざまな場所で使用できますが、それはどこでしょうか？
| アトラシアンには、暗号技術と暗号化ポリシー、および実装ガイドラインがあります。このポリシーは、PMP（ポリシー管理プログラム）に従って毎年見直され、更新されています。詳細については、https://www.atlassian.com/ja/trust/security/security-management-program をご覧ください。 |
|
| 6.04.05. (b) | 何を暗号化し、何を暗号化しないかについて、明確に定義されたポリシーはありますか？ | アトラシアンには、暗号技術と暗号化ポリシー、および実装ガイドラインがあります。このポリシーは、PMP（ポリシー管理プログラム）に従って毎年見直され、更新されています。PMP の詳細については、https://www.atlassian.com/ja/trust/security/security-management-program をご覧ください。 |
|
| 6.04.05. (d) | アクセス・キーは誰が保持していますか？ | アトラシアンでは、キー管理に AWS KMS（Key Management Service）を利用しています。暗号化、復号化、キー管理のプロセスが AWS の既存の内部検証プロセスの一部として、定期的に検査されて検証されます。各キーには所有者が割り当てられ、所有者は、適切なレベルのセキュリティ制御をキーに設定する役割を果たします。 |
|
| 6.04.05. (e) | キーはどのように保護されていますか？ | アトラシアンでは、キー管理に AWS KMS（Key Management Service）を利用しています。暗号化、復号化、キー管理のプロセスが AWS の既存の内部検証プロセスの一部として、定期的に検査されて検証されます。各キーには所有者が割り当てられ、所有者は、適切なレベルのセキュリティ制御をキーに設定する役割を果たします。 |
認証 | |||
|
| 6.04.06. (a) | 厳格な保証が必要な業務には、どのような認証方法が使われていますか？この業務には、管理インターフェイスへのログイン、キーの作成、複数ユーザー・アカウントへのアクセス、ファイアウォールの設定、リモート・アクセスなどがあります。
| アトラシアンは、NIST Special Publication 800-63B に概説されているガイドラインに従っています。参照：https://pages.nist.gov/800-63-3/sp800-63b.html |
認証情報の漏洩または盗難 | |||
| | 6.04.07. (a) | 異常検知（通常とは異なり、潜在的に悪意のある IP トラフィック、またはユーザーやサポート・チームの行動を発見する機能）はありますか？たとえば、ログインの失敗と成功の回数、異常な時間帯、複数のログインなどの分析です。 | 当社の Atlassian Cloud プラットフォームには、ファイアウォールから漏洩する部分はほとんどありません。ファイアウォールのルールを定期的にレビューしています。当社はオフィス・サイトとクラウド・ホスティング環境に IDS を導入しました。Atlassian Cloud Platform については、ログ転送をセキュリティ分析プラットフォームに統合しました。Cloud Platform のコンテナー・レベルでは、インスタンスは変更不可であるためファイルの整合性が保たれます。アトラシアンのネットワーク・エンジニアリングは、当社のファイアウォールに組み込まれた IPS テクノロジーを使用しており、オフィス環境とクラウド環境には IDS テクノロジーを実装しています。DDoS 機能は当社のインターネット・サービス・プロバイダ/通信事業者のものです。 |
|
| 6.04.07. (b) | お客様の認証情報が盗まれた場合の規定にはどのようなものがありますか（発見、取り消し、立証など）？ | アトラシアンのクラウド・サービスでは、お客様の管理下にあるサービス・ユーザーのアクセス管理について、その一部またはすべてをお客様が責任を負います。
このポリシーに基づいて、アトラシアンはセキュリティ・インシデント対応計画を維持しています。セキュリティ・インシデント対応プロセスの詳細については、https://www.atlassian.com/ja/trust/security/security-incident-management をご覧ください。 |
クラウドのお客様に提供される ID およびアクセス管理システム | |||
|
| 6.04.08. | 次の質問は、クラウド・プロバイダが提供し、クラウドのお客様が使用および管理する ID およびアクセス管理システムに適用されます。 |
|
クラウドのお客様に提供される ID およびアクセス管理システム | |||
|
| 6.04.08.01. (a) | そのシステムでは、厳密な保証（必要であれば OTP システム）と簡単な保証（ユーザー名とパスワードなど）の両方で相互運用可能なフェデレーション IDM インフラストラクチャに対応していますか？ | Atlassian Access は、アトラシアン製品（Confluence、Jira、Jira Align、Bitbucket など）全体の ID フェデレーション基準をサポートしています。Atlassian Access では、Okta、Azure AD、または OneLogin を使って、使用している Active Directory を Atlassian 製品に自動的に同期できます。詳細については、https://www.atlassian.com/ja/software/access をご覧ください。特定製品の SSO セットアップ（汎用 SAML v2.0、Google、Okta、OneLogin、PingIdentity、ADFS）：
|
|
| 6.04.08.01. (b) | クラウド・プロバイダはサードパーティ ID プロバイダと相互運用可能でしょうか？ | アトラシアンのお客様は、サポート対象であれば、選択したサードパーティ ID プロバイダを利用できます。このような機能の詳細、および選択した ID プロバイダへの接続方法については、次のアトラシアン・サポートのページをご覧ください：https://support.atlassian.com/ja/provisioning-users/docs/supported-identity-providers/ |
|
| 6.04.08.01. (c) | シングル・サインオンを組み込むことはできますか？ | アトラシアンでは、ほとんどの製品の認証で Google、Microsoft、Apple の ID の使用をサポートしています。また、Atlassian Access を通じて、アトラシアンのクラウド・サービスのための SAML もサポートしています。https://www.atlassian.com/ja/enterprise/cloud/access をご覧ください。 |
アクセス制御 | |||
|
| 6.04.08.02. (a) | クライアントの認証情報システムでは、ロールと責任を分離し、複数のドメインを指定（または複数のドメイン、ロール、責任を 1 つのキーで指定）できますか？ | アトラシアンはマルチテナント型の SaaS アプリケーションです。マルチテナントは Atlassian Cloud の重要な機能であり、それぞれの顧客テナントのアプリケーション・データを分離しながら、複数のお客様が Jira または Confluence アプリケーション・レイヤーの 1 つのインスタンスを共有できるようにします。Atlassian Cloud では TCS（テナント・コンテキスト・サービス）によってこれを実現しています。すべてのユーザー ID はそれぞれ 1 つのテナントに関連付けられ、それが Atlassian Cloud アプリケーションへのアクセスに使用されます。詳細については、https://www.atlassian.com/ja/trust/security/security-practices#tenant-isolation をご覧ください。 |
|
| 6.04.08.02. (b) | お客様のシステム・イメージへのアクセスをどのように管理し、認証と暗号化キーがそこに含まれていないことを確認していますか？ | 当社のグローバル・サポート・チームは、保守とサポートのために、ホストされているすべてのシステムとアプリケーションのアカウントを管理しています。当社サポート・チームは、アプリケーションの正常性の監視、システムまたはアプリケーションの保守、または当社のサポート・システム経由でのお客様からの依頼に基づき、ホストされているアプリケーションやデータにアクセスしています。 |
認証 | | | |
|
| 6.04.08.03. (a) | クラウド・プロバイダはお客様に対してどのようにプロバイダ自体を証明していますか（つまり、相互認証はありますか）？
| アトラシアンでは、相互認証を利用してお客様に自身を証明しています。アトラシアン API のドキュメンテーションについては、https://developer.atlassian.com/cloud/ をご覧ください。ASAP（アトラシアン・サービス認証プロトコル）はサービス間認証プロトコルであり、JWT（JSON Web トークン）を使用して実装され、アトラシアンの信頼できる機関の RSA キーによって署名されたアクセス・トークンを利用しています。詳細については、アトラシアン・サービス認証プロトコルを参照してください。アトラシアンは従来の「サービス・アカウント」の概念ではなく、サービス間の認証と承認を利用しています。 |
|
| 6.04.08.03. (b) | 認証のフェデレーション・メカニズムをサポートしていますか？ | Atlassian Access は、アトラシアン製品（Confluence、Jira、Jira Align、Bitbucket など）全体の ID フェデレーション基準をサポートしています。Atlassian Access では、Okta、Azure AD、または OneLogin を使って、使用している Active Directory を Atlassian 製品に自動的に同期できます。詳細については、https://www.atlassian.com/ja/software/access をご覧ください。特定製品の SSO セットアップ（汎用 SAML v2.0、Google、Okta、OneLogin、PingIdentity、ADFS）：
|
資産管理 | |||
|
| 6.05. | プロバイダがクラウド・プロバイダの管理下にあるハードウェアとソフトウェア（アプリケーション）資産の最新リストを維持していることを確認することが重要です。これにより、すべてのシステムに適切な制御が採用されていること、システムをインフラストラクチャへのバックドアとして使用できないことを確認できます。 |
|
|
| 6.05. (a) | プロバイダには、すべてのアセット・インベントリ作成を自動化して、適切な管理を容易にする手段がありますか？ | 当社の本番環境システムは、クラウド・サービス・プロバイダを通して取得したインフラストラクチャ内にあります。サービスの性質上、これらのシステムにはハードウェア・レベルでの追跡が行われません。当社製品の動作基盤となるマイクロサービスは、カスタムで構築した「サービス」データベース内で追跡されます。このデータベースは、サービスがデプロイされると自動的に更新されます。 |
|
| 6.05. (b) | 顧客が特定の期間に使用した資産のリストはありますか？ | アトラシアンはマルチテナント型の SaaS アプリです。マルチテナントは Atlassian Cloud の重要な機能であり、それぞれの顧客テナントのアプリケーション・データを分離しながら、複数の顧客が Jira または Confluence アプリケーション・レイヤーの 1 つのインスタンスを共有できるようにします。Atlassian Cloud ではTCS（テナント・コンテキスト・サービス）によってこれを実現しています。すべてのユーザー ID はそれぞれテナント 1 つだけに関連付けられ、それが Atlassian Cloud アプリケーションへのアクセスに使用されます。詳細については、https://www.atlassian.com/trust/security/security-practices#tenant-isolation をご覧ください。 |
|
|
| 次の質問は、エンド・カスタマーが追加の保護を必要とする（つまり、機密とみなされる）データをデプロイしている場合に使用します。 |
|
|
| 6.05. (c) | 資産は機密性と重要度の観点で分類されていますか？
| アトラシアンでは、資産とサービスについて 4 段階の格付けを維持しています。稼働時間、サービス・レベル、継続要件は階層ごとに設定されています。詳細については、https://www.atlassian.com/ja/trust/security/data-management をご覧ください。 |
データとサービスのポータビリティ | |||
|
| 6.06. | ベンダー・ロックインに関連するリスクを理解するには、この一連の質問を考慮する必要があります。 |
|
|
| 6.06. (a) | クラウドからデータをエクスポートするための文書化された手順と API はありますか？ | 顧客データは、Web アプリと API を介して利用できます。個別の製品の詳細は以下のとおりです。
|
|
| 6.06. (b) | ベンダーは、クラウド内に保存されているすべてのデータに相互運用可能なエクスポート形式を提供していますか？ | 顧客がアトラシアン製品で利用者データをホスティングする必要があるケースで、利用者からデータのエクスポート依頼があった場合は容易に行えます。製品データとユーザー・データをエクスポートするための強固なデータ・ポータビリティとデータ管理ツールをご用意しています。Atlassian Cloud のデータ・エクスポートの詳細については、インポートとエクスポートのドキュメント https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/ を参照してください。 |
|
| 6.06. (c) | SaaS の場合、使用される API インターフェイスは標準化されていますか？ | Atlassian Cloud API の詳細については、https://developer.atlassian.com/explore-the-apis/ をご確認ください。
|
|
| 6.06. (d) | ユーザーが作成したアプリケーションを標準形式でエクスポートするための規定はありますか？ | アトラシアンは SaaS（サービスとしてのソフトウェア）モデルを運用しているため、これには該当しません。 |
|
| 6.06. (e) | データを他のクラウド・プロバイダにエクスポートできることをテストするプロセスはありますか（たとえば、クライアントがプロバイダを変更したい場合など）？ | 顧客がアトラシアン製品で利用者データをホスティングする必要があるケースで、利用者からデータのエクスポート依頼があった場合は容易に行えます。製品データとユーザー・データをエクスポートするための強固なデータ・ポータビリティとデータ管理ツールをご用意しています。Atlassian Cloud のデータ・エクスポートの詳細については、インポートとエクスポートのドキュメント https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/ を参照してください。 |
|
| 6.06. (f) | クライアントが独自のデータ抽出を実行して、形式が汎用的であること、他のクラウド・プロバイダに移行できることを確認できますか？ | 顧客がアトラシアン製品で利用者データをホスティングする必要があるケースで、利用者からデータのエクスポート依頼があった場合は容易に行えます。製品データとユーザー・データをエクスポートするための強固なデータ・ポータビリティとデータ管理ツールをご用意しています。Atlassian Cloud のデータ・エクスポートの詳細については、インポートとエクスポートのドキュメント https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/ を参照してください。 |
ビジネス継続性の管理 | |||
|
| 6.07. | 継続性を提供することは組織にとって重要です。システムを利用できる最小期間を詳述したサービス・レベル・アグリーメントを設定することは可能ですが、他にも考慮すべき点がいくつかあります。 |
|
|
| 6.07. (a) | プロバイダは、中断の影響を詳述した文書化された方法を保持していますか？
| 事業継続とディザスタ・リカバリに関するポリシー、およびその計画が策定されており、事業継続/ディザスタ・リカバリ運営委員会によって毎年レビューされています。詳細（RPO、RTO、およびアベイラビリティ・ゾーンの使用による回復力に関するものを含む）については、https://www.atlassian.com/trust/security/security-practices#business-continuity-and-disaster-recovery-management と https://www.atlassian.com/trust/security/data-management をご覧ください。 |
|
| 6.07. (b) | プロバイダは復旧の優先度を分類していますか？また、私たちの復旧の相対的な優先度（エンド・カスタマー）はどれになりますか？注：これはカテゴリ（高/中/低）の場合もあります。 | ミッション・クリティカルなシステム、プロセス、またはサービスの所有者は、災害時には中断の許容度に従って、適切な BCDR（事業継続やディザスタ・リカバリ）を確実に実行します。BCDR 計画は四半期ごとに必ずテストし、課題を特定して対処します。詳細については、https://www.atlassian.com/trust/security/security-practices#business-continuity-and-disaster-recovery-management と https://www.atlassian.com/trust/security/data-management をご覧ください。 |
|
| 6.07. (c) | 復元プロセスに関連する依存関係にはどのようなものがありますか？サプライヤーとアウトソーシング・パートナーを含めてください。 | アトラシアンには、データ復元作業の手順とログがあります。大まかに言うと、これは当社の内部バックアップ標準、事業継続およびディザスタ・リカバリ・ポリシーに含まれています。ただし、アトラシアンの各サービスには、顧客主導の復元とアトラシアン主導の復元のランブック、スケジュール、手順を含むさまざまな内部文書があります。 |
|
| 6.07. (d) | プライマリ・サイトが利用できなくなった場合、セカンダリ・サイトの場所までどの程度離れている必要がありますか？ | 当社パートナーのデータ センターは、複数のコンプライアンス認証を取得しています。これらの認定は、物理的なセキュリティ、システムの可用性、ネットワークと IP バックボーン アクセス、顧客のプロビジョニング、問題管理を目的としています。データ センターへのアクセスは権限を付与された人員に限られて、生体認証手段によって検証されます。物理的なセキュリティ対策には、常駐の警備員、有線のビデオ監視、侵入者用の装置、その他の侵入保護措置が含まれます。 AWS の物理的な保護に関する保証情報については、http://aws.amazon.com/compliance/ をご覧ください。 |
インシデント管理と対応 | |||
|
| 6.07.01. | インシデント管理と対応は事業継続管理の一部です。このプロセスの目標は、予期しない出来事や中断につながる可能性のある出来事の影響を組織にとって許容できるレベルまで抑えることです。情報セキュリティ・インシデントの発生確率を最小限に抑えたり、悪影響を軽減したりするための組織の能力を評価するには、クラウド・プロバイダに次の質問をする必要があります。 |
|
|
| 6.07.01. (a) | プロバイダは、インシデントの検出、特定、分析、対応のための正式なプロセスを用意していますか？ | アトラシアンでは、以下の主要原則を含むセキュリティ・インシデント対応ポリシーを文書化しています。
このポリシーに基づいて、アトラシアンはセキュリティ・インシデント対応計画を維持しています。セキュリティ・インシデント対応プロセスの詳細については、https://www.atlassian.com/trust/security/security-incident-management をご覧ください。 ログが読み取り専用となっている各システムから、重要なシステム・ログが中央のログ記録用プラットフォームに転送されます。アトラシアン・セキュリティ・チームでは、セキュリティ分析プラットフォーム（Splunk）上でアラートを作成し、セキュリティ侵害の兆候を監視します。SRE チームでは、このプラットフォームを使用して、可用性またはパフォーマンスの問題を監視します。ログは、ホット・バックアップで 30 日間、コールド・バックアップで 365 日間保持されます。 アトラシアンの検出プログラムの詳細については、https://www.atlassian.com/trust/security/detections-program を参照してください。 |
|
| 6.07.01. (b) | このプロセスは、インシデント処理プロセスが効果的であることを確認するために予行演習が実行されますか？プロバイダは、予行演習中に、クラウド・プロバイダのサポート組織内の全員が、インシデント処理中（インシデント中と分析後の両方）のプロセスと役割を認識していることも確認していますか？ | Atlassian Cloud サービスでは、ビジネス継続性計画とディザスタ・リカバリ計画を少なくとも四半期ごとにテストしています。複数のリージョンの可用性がリアルタイムで監視されています。自動リージョン・フェイルオーバー・テストは、本番前環境で毎週実施されています。構成データの自動復元テストは、本番環境で毎日実施されています。アトラシアンのすべてのサービスは、四半期ごとに本番前環境でアベイラビリティ・ゾーンの回復力テストを実施しています。事業継続プログラムの詳細については、https://www.atlassian.com/trust/security/security-practices#faq-d323ae61-59b8-4ddb-96d4-30716b603e3e をご覧ください。 |
|
| 6.07.01. (c) | 検出機能はどのように構成されていますか？
| 当社の Atlassian Cloud プラットフォームには、ファイアウォールから漏洩する部分はほとんどありません。ファイアウォールのルールを定期的にレビューしています。当社はオフィス・サイトとクラウド・ホスティング環境に IDS を導入しました。Atlassian Cloud Platform については、ログ転送をセキュリティ分析プラットフォームに統合しました。Cloud Platform のコンテナー・レベルでは、インスタンスは変更不可であるためファイルの整合性が保たれます。アトラシアンのネットワーク・エンジニアリングは、当社のファイアウォールに組み込まれた IPS テクノロジーを使用しており、オフィス環境とクラウド環境には IDS テクノロジーを実装しています。DDoS 機能は当社のインターネット・サービス・プロバイダ/通信事業者のものです。アトラシアンの検出プログラムの詳細については、https://www.atlassian.com/ja/trust/security/detections-program をご覧ください。ログが読み取り専用となっている各システムから、重要なシステム・ログが中央のログ記録用プラットフォームに転送されます。アトラシアン・セキュリティ・チームでは、セキュリティ分析プラットフォーム（Splunk）上でアラートを作成し、セキュリティ侵害の兆候を監視します。SRE チームでは、このプラットフォームを使用して、可用性またはパフォーマンスの課題を監視します。ログは、ホット・バックアップで 30 日間、コールド・バックアップで 365 日間保持されます。アトラシアン監査ログの表示と読み取りは、中央のログ記録用プラットフォームで権限を付与された担当者に制限されています。アトラシアンでは、バグ報奨金プログラム、カスタマー・サポート・ポータル、所定のセキュリティ・メール受信トレイや電話番号など、外部のレポート・チャネルを脆弱性やインシデントの検知に使用しており、不正なアクセスや悪意のある行為を報告するようお客様にお願いしています。詳細については、https://www.atlassian.com/ja/trust/security/security-incident-management および https://www.atlassian.com/ja/trust/security/security-incident-responsibilities をご覧ください。 |
|
| 6.07.01. (d) | 重大度レベルはどのように定義されていますか？ | アトラシアンでは、発見された脆弱性ごとにセキュリティ・リスクと優先順位を評価する方法として、CVSS（共通脆弱性評価システム）を使用します。使用するセキュリティ・レベルは、次のようなアトラシアン独自の計算による CVSS スコアに基づいています。
重大度が決まるスコア範囲など、詳細については、https://www.atlassian.com/ja/trust/security/security-severity-levels をご覧ください。 |
|
| 6.07.01. (e) | エスカレーション手順はどのように定義されていますか？クラウドのお客様は（該当する場合）どの時点で関与しますか？ | アトラシアンでは、以下の主要原則を含むセキュリティ・インシデント対応ポリシーを文書化しています。
このポリシーに基づいて、アトラシアンはセキュリティ・インシデント対応計画を維持しています。セキュリティ・インシデント対応プロセスの詳細については、https://www.atlassian.com/ja/trust/security/security-incident-management をご覧ください。 アトラシアンは、データ侵害があった場合に速やかに通知を受けることがいかに重要かを理解しています。そのため https://www.atlassian.com/ja/trust/security/security-incident-management で述べているように、セキュリティ・インシデントを処理するための広範な部門横断型チームを編成し、プロセスを構築しました。 アトラシアンには、インシデントをタイムリーかつ積極的に通知し、必要な緩和策についてお客様と協力してきた確かな実績があります。 インシデントの発生後は、アトラシアンのセキュリティ・インシデント対応チームが速やかに優先順位付けと軽減にあたることが重要であるため、72 時間のタイムラインには同意できません。代わりに、データ処理者に関する GDPR の法的要件に従い、ほぼすべてのお客様の正当なニーズを満たせるよう、「不当に遅滞することなく」お客様に通知します。 インシデントは単純なものから非常に複雑なものまでさまざまあるため、アトラシアンでは、法の下で必要となるものは提供できますが、「すべてに対応する」タイムラインには同意できません。 |
|
| 6.07.01. (f) | どのようにしてインシデントが文書化され、証拠が収集されるのですか？ | 追跡と修復のために Jira チケットが作成され、重大度と脆弱性の原因に基づき、SLO に従って期限が割り当てられます。特定された脆弱性に関するチケットをシステム所有者に発行する継続的なプロセスがあり、セキュリティ管理チームが報告された脆弱性をレビューし、それに対して対策が講じられていることを確認します。 |
|
| 6.07.01. (g) | 認証、会計、監査以外に、内部者による悪意のある活動を防ぐ（または影響を最小限に抑える）ために他にどのような制御が行われていますか？ | アトラシアンはオフィス・サイトとクラウド・ホスティング環境に IDS を導入しました。Atlassian Cloud Platform については、ログ転送をセキュリティ分析プラットフォームに統合し、ログが読み取り専用となっている各システムから、重要なシステム・ログが中央のログ記録用プラットフォームに転送されます。アトラシアン・セキュリティ・チームでは、セキュリティ分析プラットフォーム（Splunk）上でアラートを作成し、セキュリティ侵害の兆候を監視します。アトラシアンの検出プログラムの詳細については、https://www.atlassian.com/ja/trust/security/detections-program をご覧ください。 |
|
| 6.07.01. (h) | プロバイダはインシデントの指標（例：1 か月あたりに検出または報告されたインシデントの数、クラウド・プロバイダの下請業者が引き起こしたインシデントの数、そのようなインシデントの総数、対応と解決までの平均時間など）を収集していますか？
| 現時点では、アトラシアン内部の指標は公開していませんが、Statuspage で SEV 0 または SEV 1 の運用インシデントに関するインシデント発生後アクションを公開しています。詳細は、https://status.atlassian.com/ をご覧ください。 |
|
| 6.07.01. (j) | プロバイダはディザスタ・リカバリ計画とビジネス継続性計画をどのくらいの頻度でテストしていますか？ | Atlassian Cloud サービスでは、ビジネス継続性計画とディザスタ・リカバリ計画を少なくとも四半期ごとにテストしています。複数のリージョンの可用性がリアルタイムで監視されています。自動リージョン・フェイルオーバー・テストは、本番前環境で毎週実施されています。構成データの自動復元テストは、本番環境で毎日実施されています。アトラシアンのすべてのサービスは、四半期ごとに本番前環境でアベイラビリティ・ゾーンの回復力テストを実施しています。ビジネス継続性プログラムの詳細については、https://www.atlassian.com/ja/trust/security/security-practices をご覧ください。 |
|
| 6.07.01. (k) | プロバイダは SLA に対する満足度に関してデータを収集していますか？ | アトラシアンは Cloud インスタンスのパフォーマンスと可用性を監視していますが、現時点では正式なアプリケーションの可用性 SLA は提供していません。当社のサポート・チームは初回応答時間の SLA を提供しています。公式のサポート解決 SLA はありませんが、内部目標として、割り当てられたすべてのケースを 48 時間以内に解決するとしています。アトラシアンでは、最新の Cloud システム・ステータスの統計を https://status.atlassian.com に示しています。 |
|
| 6.07.01. (l) | プロバイダは次のようなヘルプ・デスクのテストを実施していますか？
| アトラシアンでは、オンボーディング・トレーニング（「Day 1」）の一環として新入社員向けに、また全スタッフに対して継続的な情報セキュリティ・トレーニングを提供しています。 |
|
| 6.07.01. (m) | プロバイダはペネトレーション・テストを実施していますか？その頻度は？ペネトレーション・テストでは実際に何をテストしますか？たとえば、各イメージのセキュリティ分離をテストし、あるイメージから別のイメージへの「ブレーク・アウト」やホスト・インフラストラクチャへのアクセスが不可能であることを確認するのですか？テストでは、仮想イメージを介してクラウド・プロバイダの管理システムとサポート・システム（プロビジョニングや管理者アクセスの制御システムなど）にアクセスできるかどうかも確認する必要があります。 | アトラシアンでは、すべてのインフラストラクチャ、クラウド・サービス、および人材の継続的なペネトレーション・テストを実施する社内レッド・チームを編成しています。 |
|
| 6.07.01. (n) | プロバイダは脆弱性テストを実施していますか？その頻度は？ | アトラシアン・セキュリティ・チームは、業界で認められている脆弱性スキャナーを使用し、内部インフラストラクチャと外部インフラストラクチャの両方のネットワーク脆弱性スキャンを継続的に実施しています。当社の脆弱性管理プログラムの詳細については、https://www.atlassian.com/ja/trust/security/vulnerability-management をご覧ください。 |
|
| 6.07.01. (o) | 脆弱性を解決するプロセスはどのようなものですか（ホット・フィックス、再構成、最新バージョンのソフトウェアへのアップリフトなど）？ | 追跡と修復のために Jira チケットが作成され、重大度と脆弱性の原因に基づき、SLO に従って期限が割り当てられます。特定された脆弱性に関するチケットをシステム所有者に発行する継続的なプロセスがあり、セキュリティ管理チームが報告された脆弱性をレビューし、それに対して対策が講じられていることを確認します。 |
物理的なセキュリティ | |||
|
| 6.08. | 人事セキュリティと同様に、潜在的な課題の多くは、IT インフラストラクチャがサードパーティ管理下にあるために発生します。つまり、従来のアウトソーシングと同様に、物理的なセキュリティ侵害の影響は複数のお客様（組織）に影響を与える可能性があります。 |
|
|
| 6.08. (a) | その場所の物理的なセキュリティに関して、お客様にどのような保証ができますか？その例、および ISO 27001/2 のセクション 9 などに準拠する基準を示してください。 | アトラシアンのオフィスにおける物理的なセキュリティ・コントロールは、物理的および環境的なセキュリティ・ポリシーに基づき、オンプレミスおよびクラウドの環境全体で堅牢な物理的セキュリティが確実に実施されるようにしています。 |
|
| 6.08. (a) (i) | 権限のある IT 担当者以外で、付き添いなしで IT インフラストラクチャに（物理的に）アクセスできるのは誰ですか？
| アトラシアンのオフィスは、物理的な出入り口の監視などを含め、社内の物理および環境面でのセキュリティ・ポリシーに従っています。アトラシアン社内のテクノロジー・オペレーションとセキュリティ・ポリシーについては、https://www.atlassian.com/ja/trust/security/ismp-policies で抜粋しています。 |
|
| 6.08. (a) (ii) | アクセス権はどのくらいの頻度で見直されますか？
| アトラシアンでは、適切な指標を使用して ISMS のパフォーマンスと効果を評価しています。当社は内部および外部の監査レビューを通じて、ATMS（Atlassian Trust Management System）と関連するコントロールのパフォーマンスを監視しています。アトラシアンのコンプライアンス・チームは、内部監査/準備体制の社内監査スケジュールと外部監査スケジュールの両方を管理しており、どちらも社内の監査ロードマップ・ページで文書化されています。内部監査はアトラシアン全体でリスクの高い領域に焦点を当て、あらかじめ決められたスケジュール、およびリスク/コンプライアンス・チームと内部監査チームとの間で合意した Enterprise 監査スケジュールに従って定期的に行われます。現時点では、アトラシアン内部の指標は公開していません。ATMS は、独立したサードパーティによって毎年、かつ大きな変更があった場合に評価されます。アトラシアンは主要なクラウド・サービスのそれぞれについて SOC 2、ISO27001、および ISO7018 の認証を取得しています。また、ATMS の柱については、それぞれ特定の指標を使用する運用レビュー・ミーティングを定期的に実施し、監視しています。これには、ATMS やその他のミーティングの毎週のコンプライアンスに関する健全性レビューが含まれ、そのレビューは社内で ATMS：コンプライアンス健全性のレビュー・ページと ATMS ミーティング議事録ページで文書化されています。詳細については、https://www.atlassian.com/ja/trust/compliance をご覧ください。 |
|
| 6.08. (a) (iii) | セキュリティ・リスクを評価し、境界を定期的に評価していますか？
| アトラシアンでは、適切な指標を使用して ISMS のパフォーマンスと効果を評価しています。当社は内部および外部の監査レビューを通じて、ATMS（Atlassian Trust Management System）と関連するコントロールのパフォーマンスを監視しています。アトラシアンのコンプライアンス・チームは、内部監査/準備体制の社内監査スケジュールと外部監査スケジュールの両方を管理しており、どちらも社内の監査ロードマップ・ページで文書化されています。内部監査はアトラシアン全体でリスクの高い領域に焦点を当て、あらかじめ決められたスケジュール、およびリスク/コンプライアンス・チームと内部監査チームとの間で合意した Enterprise 監査スケジュールに従って定期的に行われます。現時点では、アトラシアン内部の指標は公開していません。ATMS は、独立したサードパーティによって毎年、かつ大きな変更があった場合に評価されます。アトラシアンは主要なクラウド・サービスのそれぞれについて SOC 2、ISO27001、および ISO7018 の認証を取得しています。また、ATMS の柱については、それぞれ特定の指標を使用する運用レビュー・ミーティングを定期的に実施し、監視しています。これには、ATMS やその他のミーティングの毎週のコンプライアンスに関する健全性レビューが含まれ、そのレビューは社内で ATMS：コンプライアンス健全性のレビュー・ページと ATMS ミーティング議事録ページで文書化されています。詳細については、https://www.atlassian.com/ja/trust/compliance をご覧ください。 |
|
| 6.08. (a) (iv) | 近隣の建物などを含め、リスク評価を定期的に実施していますか？ | アトラシアンでは、適切な指標を使用して ISMS のパフォーマンスと効果を評価しています。当社は内部および外部の監査レビューを通じて、ATMS（Atlassian Trust Management System）と関連するコントロールのパフォーマンスを監視しています。アトラシアンのコンプライアンス・チームは、内部監査/準備体制の社内監査スケジュールと外部監査スケジュールの両方を管理しており、どちらも社内の監査ロードマップ・ページで文書化されています。内部監査はアトラシアン全体でリスクの高い領域に焦点を当て、あらかじめ決められたスケジュール、およびリスク/コンプライアンス・チームと内部監査チームとの間で合意した Enterprise 監査スケジュールに従って定期的に行われます。現時点では、アトラシアン内部の指標は公開していません。ATMS は、独立したサードパーティによって毎年、かつ大きな変更があった場合に評価されます。アトラシアンは主要なクラウド・サービスのそれぞれについて SOC 2、ISO27001、および ISO7018 の認証を取得しています。また、ATMS の柱については、それぞれ特定の指標を使用する運用レビュー・ミーティングを定期的に実施し、監視しています。これには、ATMS やその他のミーティングの毎週のコンプライアンスに関する健全性レビューが含まれ、そのレビューは社内で ATMS：コンプライアンス健全性のレビュー・ページと ATMS ミーティング議事録ページで文書化されています。詳細については、https://www.atlassian.com/ja/trust/compliance をご覧ください。 |
|
| 6.08. (a) (v) | セキュリティ保護されている場所にアクセスする人員（サードパーティを含む）を管理または監視していますか？ | アトラシアンのオフィスは、物理的な出入り口の監視などを含め、社内の物理および環境面でのセキュリティ・ポリシーに従っています。アトラシアン社内のテクノロジー・オペレーションとセキュリティ・ポリシーについては、https://www.atlassian.com/ja/trust/security/ismp-policies で抜粋しています。 |
|
| 6.08. (a) (vi) | 機器の積み込み、荷降ろし、設置について、どのようなポリシーや手順がありますか？ | アトラシアンのオフィス施設では、荷物搬入口は作業エリアから隔離されており、CCTV とビル・スタッフによって常に監視されています。データ・センターのホスティング・パートナーは物理的なセキュリティを管理しており、効果的な制御の確認についてはパートナーのコンプライアンス証明書を採用しています。 |
|
| 6.08. (a) (vii) | 配送されたものについて設置前にリスク検査を実施していますか？ | アトラシアンのオフィス施設では、荷物搬入口は作業エリアから隔離されており、CCTV とビル・スタッフによって常に監視されています。データ・センターのホスティング・パートナーは物理的なセキュリティを管理しており、効果的な制御の確認についてはパートナーのコンプライアンス証明書を採用しています。 |
|
| 6.08. (a) (viii) | データ・センターにあるアイテムの棚卸は最新ですか？ | アトラシアンのアセット管理ポリシーについては、https://www.atlassian.com/ja/trust/security/ismp-policies で抜粋しています。アトラシアンは、アセット所有者とともにすべての生産アセットのインベントリを管理しています。アトラシアンのシステムはすべて AWS ベースのデータ・センターにあります。サービスの性質上、当社の AWS システムにはハードウェア・レベルでの追跡が行われません。 |
|
| 6.08. (a) (ix) | ネットワーク・ケーブルは公共のアクセス・エリアを経由していますか？
| アトラシアンのオフィスは、物理的な出入り口の監視などを含め、社内の物理および環境面でのセキュリティ・ポリシーに従っています。アトラシアン社内のテクノロジー・オペレーションとセキュリティ・ポリシーについては、https://www.atlassian.com/ja/trust/security/ismp-policies で抜粋しています。 |
|
| 6.08. (a) (x) | 認証されていない機器を検出するため、定期的に建物を調査していますか？ | アトラシアンのアセット管理ポリシーについては、https://www.atlassian.com/ja/trust/security/ismp-policies で抜粋しています。アトラシアンは、アセット所有者とともにすべての生産アセットのインベントリを管理しています。アトラシアンのシステムはすべて AWS ベースのデータ・センターにあります。サービスの性質上、当社の AWS システムにはハードウェア・レベルでの追跡が行われません。 |
|
| 6.08. (a) (xi) | オフサイトの機器を使用していますか？
| アトラシアンのアセット管理ポリシーについては、https://www.atlassian.com/ja/trust/security/ismp-policies で抜粋しています。アトラシアンは、アセット所有者とともにすべての生産アセットのインベントリを管理しています。アトラシアンのシステムはすべて AWS ベースのデータ・センターにあります。サービスの性質上、当社の AWS システムにはハードウェア・レベルでの追跡が行われません。 |
|
| 6.08. (a) (xii) | データ・センターにアクセスできるポータブル機器（データ・センターにアクセスできるノート PC、スマートフォンなど）を使っている従業員はいますか？
| 当社パートナーのデータ・センターは、複数のコンプライアンス認定を取得しています。これらの認証は、物理的なセキュリティ、システムの可用性、ネットワークと IP バックボーン・アクセス、顧客のプロビジョニング、問題管理を目的としています。データ・センターへのアクセスは権限を付与された人員に限られ、生体認証手段によって検証されます。物理的なセキュリティ対策には、常駐の警備員、有線のビデオ監視、侵入者用の装置、その他の侵入保護措置が含まれます。AWS の物理的な保護に関する保証情報については、http://aws.amazon.com/compliance/ をご覧ください。 |
|
| 6.08. (a) (xiii) | アクセス・カードを管理するために、どのような対策が講じられていますか？ | アトラシアンのオフィスは、物理的な出入り口の監視などを含め、社内の物理および環境面でのセキュリティ・ポリシーに従っています。アトラシアン社内のテクノロジー・オペレーションとセキュリティ・ポリシーについては、https://www.atlassian.com/ja/trust/security/ismp-policies で抜粋しています。 |
|
| 6.08. (a) (xiv) | 古いメディアやシステムを破棄する必要がある場合のプロセスや手順はどのようなものですか？
| このプロセスはワークプレース・テクノロジーで処理され、機器は適切にデータを消去され、消磁されます。アトラシアンには、クラウド製品やサービスをサポートする物理メディアはありません。 |
|
| 6.08. (a) (xv) | あるサイトから別のサイトへの機器の移動には、どのような承認プロセスが採られていますか？
| アトラシアンのデータ・センター・ホスティング・パートナー（AWS）は物理的なセキュリティを管理しており、その制御の効果検証には AWS の SOC2 を利用しています。 |
|
| 6.08. (a) (xvi) | 機器の不正な取り外しを監視する機器監査はどのくらいの頻度で実施されていますか？ | アトラシアンのデータ・センター・ホスティング・パートナー（AWS）は物理的なセキュリティを管理しており、その制御の効果検証には AWS の SOC2 を利用しています。 |
|
| 6.08. (a) (xvii) | 環境が法的および規制上の要件に適切に準拠していることの確認は、どのくらいの頻度で行われますか？ | アトラシアンの法務チームとコンプライアンス・チームが法令順守を監視しています。アトラシアンの法務プログラムについては、https://www.atlassian.com/ja/legal/ をご覧ください。当社のコンプライアンス・プログラムの詳細については、https://www.atlassian.com/ja/trust/compliance をご覧ください。 |
環境コントロール | |||
|
| 6.09. (a) | 環境上の課題によってサービスを中断させないために、どのような手順やポリシーが定められていますか？ | アトラシアンのオフィスは、物理的な出入り口の監視などを含め、社内の物理および環境面でのセキュリティ・ポリシーに従っています。 |
|
| 6.09. (b) | 火災、洪水、地震などによる被害を防ぐために、どのような手段がありますか？
| アトラシアンは、データ・センターのセキュリティと環境管理の検証をパートナーのデータ・ホスティング・パートナーに依存しています。AWS については、https://aws.amazon.com/compliance/programs を参照してください。 |
|
| 6.09. (c) | データ・センターの温度と湿度を監視していますか？
| アトラシアンは、データ・センターのセキュリティと環境管理の検証をパートナーのデータ・ホスティング・パートナーに依存しています。AWS については、https://aws.amazon.com/compliance/programs を参照してください。 |
|
| 6.09. (d) | 建物は落雷から守られていますか？
| アトラシアンは、データ・センターのセキュリティと環境管理の検証をパートナーのデータ・ホスティング・パートナーに依存しています。AWS については、https://aws.amazon.com/compliance/programs を参照してください。 |
|
| 6.09. (e) | 停電に備え、スタンドアロンの発電機はありますか？
| アトラシアンは、データ・センターのセキュリティと環境管理の検証をパートナーのデータ・ホスティング・パートナーに依存しています。AWS については、https://aws.amazon.com/compliance/programs を参照してください。 |
|
| 6.09. (f) | すべてのユーティリティ（電気、水道など）は環境を十分にサポートできていますか？
| アトラシアンは、データ・センターのセキュリティと環境管理の検証をパートナーのデータ・ホスティング・パートナーに依存しています。AWS については、https://aws.amazon.com/compliance/programs を参照してください。 |
|
| 6.09. (g) | 空調は環境を十分にサポートできていますか？
| アトラシアンは、データ・センターのセキュリティと環境管理の検証をパートナーのデータ・ホスティング・パートナーに依存しています。AWS については、https://aws.amazon.com/compliance/programs を参照してください。 |
|
| 6.09. (h) | メーカーが推奨するメンテナンス・スケジュールを守っていますか？ | アトラシアンは、データ・センターのセキュリティと環境管理の検証をパートナーのデータ・ホスティング・パートナーに依存しています。AWS については、https://aws.amazon.com/compliance/programs を参照してください。 |
|
| 6.09. (i) | 現場には、許可されているメンテナンス・スタッフや修理スタッフだけが出入りしていますか？
| オフィス施設への物理的なアクセスは、電子バッジ・アクセス、訪問者のサインインが必須の営業時間受付、建物のすべての出入口にある CCTV によって保護されています。荷物搬入口は、CCTV とビル・スタッフによって常に監視されています。データ・センターのホスティング・パートナーは物理的なセキュリティを管理しており、効果的な制御の確認についてはパートナーのコンプライアンス証明書を採用しています。 |
|
| 6.09. (j) | 機器を修理に送ると、その機器のデータは最初に消去されますか？
| このプロセスはワークプレース・テクノロジーで処理され、機器は適切にデータを消去され、消磁されます。アトラシアンには、クラウド製品やサービスをサポートする物理メディアはありません。 |
法的要件 | |||
|
| 6.10. | クラウド・プロバイダ・サービスの顧客や見込み客は、それぞれの国および国を超えたコンプライアンス義務と規制の枠組みを考慮し、そのような義務を適切に果たしていることを確認する必要があります。 |
|
|
| 6.10. (a) | クラウド・プロバイダはどの国にありますか？ | アトラシアンはシドニー、アムステルダム、アンカラ、ボストン、バンガロール、サンフランシスコ、マウンテンビュー、テキサス州オースティン、ニューヨーク、マニラ、グダニスク、日本で、8 か国 12 のオフィスを構えています。詳細については、https://www.atlassian.com/ja/company/contact/japan を参照してください。 |
|
| 6.10. (b) | クラウド・プロバイダのインフラストラクチャは同一国内にあるのでしょうか、または別の国でしょうか？ | Atlassian Cloud では、現在、冗長性のある AWS アベイラビリティ・ゾーン内でホストされています。特定のリージョンの詳細については、https://www.atlassian.com/ja/trust/reliability/infrastructure を参照してください。 |
|
| 6.10. (c) | クラウド・プロバイダでは、インフラストラクチャがクラウド・プロバイダ以外にある他の企業を利用していますか？ | アトラシアンのクラウド製品とデータは、業界をリードするクラウド・プロバイダである Amazon Web Services（AWS）でホストされています。アトラシアン製品は PaaS（サービスとしてのプラットフォーム）環境で動作します。この環境は Micros と non-Micros という 2 つの主要なインフラストラクチャに分けられます。Jira、Confluence、Statuspage、Access、Bitbucket は Micros プラットフォームで、Opsgenie と Trello は non-Micros プラットフォームで動作します。 |
|
| 6.10. (d) | データの物理的な保存場所は？ | アトラシアンは、米国東部、米国西部、アイルランド、フランクフルト、シンガポール、シドニーの各リージョンで AWS（Amazon Web Services）を利用しています（Confluence および Jira）。
データ・レジデンシーの詳細については、https://support.atlassian.com/security-and-access-policies/docs/understand-data-residency/ をご覧ください。 |
|
| 6.10. (e) | 契約条件とデータに関する管轄権は分割されますか？ | アトラシアンの顧客契約のデフォルトの準拠法はカリフォルニア州法です。詳細については、エンタープライズ・セールス・チームにお問い合わせください。 |
|
| 6.10. (f) | クラウド・プロバイダのサービスは外注されますか？ | アトラシアンは、サードパーティの下請け業者と協働し、Web サイト、アプリケーションの開発、ホスティング、保守、バックアップ、ストレージ、仮想インフラストラクチャ、支払い決済、分析、その他のサービスを提供しています。こうした業務において、当該サードパーティであるサービス・プロバイダが PII にアクセスする、または処理する必要が生じることがあります。 |
|
| 6.10. (g) | クラウド・プロバイダのサービスはアウトソーシングされますか？ | アトラシアンがサードパーティのサプライヤーと契約関係にある場合、契約により当社のお客様またはお客様のデータが危険にさらされることがないよう注力しています。アトラシアンの法務部門と調達部門は、契約、SLA、およびベンダー内部ポリシーを確認して、ベンダーがセキュリティ、可用性、機密保持の要件を満たしているかどうかを判断します。詳細については、https://www.atlassian.com/ja/trust/security/security-practices#supplier-risk-management をご参照ください。 |
|
| 6.10. (h) | 顧客および顧客の顧客から提供されたデータを収集、処理、転送する方法は？ | アトラシアンは、情報を収集した目的や、その後個人が承認した目的に合った方法で情報を処理します。特に、アトラシアンの外部プライバシー・ポリシーに従って処理します。 |
|
| 6.10. (i) | 契約終了時、クラウド・プロバイダに送信されたデータはどうなりますか？ | アトラシアンは、さまざまな種類のデータをどのくらいの期間、保持しなければならないかを示すデータ保持および破壊基準に従っています。データは、アトラシアンのデータ・セキュリティおよび情報のライフサイクル・ポリシーに従って分類され、それに基づいてコントロールが実装されます。顧客データについては、アトラシアンとの契約が終了すると、顧客チームに属するデータは本稼働中のデータベースから削除され、アトラシアンに直接アップロードされた添付ファイルはすべて 14 日以内に削除されます。チームのデータは暗号化され、バックアップに残りますが、90 日間のバックアップ保持期間を過ぎるとアトラシアンのデータ保持ポリシーに従って破棄されます。データ削除が要求されてから 90 日以内にデータベース復元が必要になった場合、運用チームは、本稼働中のシステムが完全に復元された後、可能な限り速やかにデータを再削除します。詳細については、https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/ を参照してください。 |