ENISA: 유럽 네트워크 및 정보 보안 기관
Atlassian 아웃소싱 가이드라인
고지 사항
아래에 제공된 가이드의 유일한 목적은 Atlassian의 Cloud 제품 및 관련 서비스를 평가할 때 비즈니스 기능을 Cloud에 아웃소싱하는 것을 고려 중인, 유럽 Cloud 고객과 엔터프라이즈 조직을 지원하기 위한 것입니다.
이 보고서는 전적으로 Atlassian Cloud 고객에게 Atlassian이 ENISA IAF를 준수하는 방법에 관한 정보 및 안내를 제공하기 위해 마련되었습니다. 이와 동시에 Atlassian은 Atlassian과 같은 Cloud 서비스 공급자("CSP") 및 그 고객이 ENISA IAF를 준수할 때 염두에 둬야 할 공동 책임에 관해 설명하는 전용 공동 책임 백서를 갖추고 있습니다. 이 공동 책임 모델이 Atlassian Cloud 제품을 사용하는 고객의 책임 및 위험을 없애 주는 것은 아니지만, 고객은 시스템 컴포넌트 및 시설의 물리적 컨트롤을 관리 및 제어하거나 보안 및 컴플라이언스 비용의 일부를 고객이 아닌 Atlassian의 부담으로 돌리는 방법 등을 통해 부담을 줄일 수 있습니다.
고객 데이터 보호를 위한 Atlassian의 노력에 대해 자세히 알아보려면 보안 관행 페이지를 참조하세요.
| | ID | ENISA 가이드 | Atlassian 대응 |
소개 | |||
|
|
| 유럽 네트워크 및 정보 보안 기관(ENISA)은 네트워크 및 정보 전문성의 중심 역할을 합니다. EU 회원국 및 민간 부문과 긴밀하게 협력하여 적절한 사이버 보안 관행에 대한 조언 및 권고를 제공합니다. ENISA는 또한 국가 정보 보안과 관련된 EU 정책 및 법률의 개발 및 시행을 지원합니다. | Atlassian은 IAF 보증 기준 및 ISO 27001 인증을 따르는 CCM(Cloud Control Matrix) 도메인 및 컨트롤에 부합하는 CSA(Cloud Security Alliance)의 CCM을 준수하여 IAF를 따릅니다.
다음 가이드는 조직이 클라우드 서비스 공급자를 선택하는 데 도움이 되도록 보증 기준에 관해 설명합니다. 특정 세부 정보에 대해 궁금한 점이 있는 경우 https://www.atlassian.com/enterprise/contact?formType=product-features를 통해 엔터프라이즈 영업 팀에 문의하세요. |
정보 보증 프레임워크(IAF) | |||
인적 보안 | |||
| | 6.01 | 인사에 관한 대부분의 질문은 담당 IT 직원 또는 IT를 담당하는 다른 직원에게 묻는 질문과 비슷할 것입니다. 대부분의 평가와 마찬가지로 위험 및 비용 사이에서 균형을 잡아야 합니다. |
|
| 6.01. (a) | IT 관리자 또는 시스템에 액세스하는 다른 담당자를 고용할 때 어떤 정책 및 절차를 사용합니까? 여기에는 다음 사항이 포함되어야 합니다.
| 거주지의 법률에 따라 신규 Atlassian 직원은 신원 조사를 완료해야 합니다. 거주지의 법률에 따라 인수를 통해 새로 고용된 직원은 인수일 이후에 신원 조사를 실시합니다. 모든 신규 직원 및 독립 계약자에 대해 범죄 조사를 실시하며, 역할이나 직급에 따라 필요한 경우 학력 확인, 고용 확인, 신용 확인을 추가로 실시합니다. Atlassian은 고위 경영진 및 회계 관련 직원들에 대해 완전한 신원 조사를 실시합니다. | |
| 6.01. (b) | 데이터가 저장되는 위치 또는 애플리케이션이 실행되는 위치에 따라 정책이 다릅니까?
| Atlassian은 직무 및 책임을 위해 최소 권한을 기반으로 Atlassian의 시스템, 애플리케이션, 인프라에 액세스해야 하는 직원을 제한하며, Atlassian의 인증 프로세스를 통해 그러한 제한을 시행합니다. 모든 액세스는 인증된 세션을 통해 이루어지고, 설정된 권한을 기반으로 합니다. | |
| 6.01. (c) | 모든 직원을 대상으로 어떤 보안 교육 프로그램을 운영합니까? | Atlassian은 신규 직원을 위한 온보딩 교육('1일 차') 중 하나로, 그리고 모든 직원에게 지속적으로 정보 보안 교육을 제공합니다. 일반 정보 보안 교육 외에도 개발자에게 보안 코딩에 대한 더 구체적인 교육을 제공하며, 이러한 교육은 포함된 보안 엔지니어 프로그램을 통해 지원됩니다. 맬웨어, 피싱 및 기타 보안 문제와 관련된 주제별 교육도 지속적으로 제공하고 있습니다. 자세한 내용은 https://www.atlassian.com/trust/security/security-practices#security-awareness-training을 참조하세요 | |
| 6.01. (d) | 지속적인 평가 프로세스가 있습니까?
| Atlassian은 Cloud 서비스에 대해 SOC2, ISO27001, ISO27018 인증을 받았습니다. 내부/준비 상태 감사 및 외부 감사를 모두 적어도 1년에 한 번 수행합니다. Atlassian은 여러 제품에 대해 정기적인 위험 평가 및 데이터 관행 검토를 요구하는 ISO 인증을 받았습니다. | |
공급망 보증 | |||
| | 6.02. | 다음 질문은 클라우드 공급자가 운영 보안의 핵심인 일부 작업을 제3자에게 하도급을 줄 때 적용됩니다(예: 기본 플랫폼을 제3자 공급자에게 아웃소싱하는 SaaS 공급자, 보안 서비스를 관리 보안 서비스 공급자에게 아웃소싱하는 클라우드 공급자, 운영 체제의 ID 관리를 위한 외부 공급자 사용 등). 여기에는 클라우드 공급자 인프라에 물리적으로 또는 원격으로 액세스할 수 있는 제3자도 포함됩니다. 이 전체 설문 조사를 제3자(또는 제n자) 클라우드 서비스 공급자에 재귀적으로 적용할 수 있다고 가정합니다. |
|
| 6.02. (a) | 운영의 보안에서 핵심이 되는 서비스 제공 공급망에서 아웃소싱되거나 하도급을 주는 서비스를 정의합니다(업무 가능 상태 포함). | Atlassian은 제3자 하위 계약업체와 협력하여 웹 사이트, 애플리케이션 개발, 호스팅, 유지 관리, 백업, 스토리지, 가상 인프라, 결제 처리, 분석 및 기타 서비스를 제공합니다. 현재 Atlassian이 사용하고 고객이 승인한 하위 프로세서 목록은 https://www.atlassian.com/legal/sub-processors에 나와 있습니다. | |
| 6.02. (b) | 제3자가 인프라(물리적 및/또는 논리적)에 액세스하도록 하는 데 사용되는 절차를 자세히 설명합니다.
| Atlassian의 법무 팀 및 조달 팀은 계약, SLA 및 공급업체 내부 정책을 검토하여 보안, 업무 가능 상태 및 기밀 유지와 관련된 위험을 관리합니다. 위험 프로필에 따라 필요한 경우 기능적 위험 평가도 수행합니다. 위험 평가는 정책 갱신의 일부로 그리고 공급자와의 관계가 크게 바뀔 때마다 다시 검토됩니다. 이 프로세스는 Atlassian의 공급자 및 제3자 데이터 관리 정책에서 다루며 발췌 내용은 다음 페이지에서 확인할 수 있습니다: https://www.atlassian.com/trust/security/ismp-policies | |
| 6.02. (c) | 아웃소싱이 보장하는 SLA 조항은 여러분이 고객에게 제공하는 SLA보다 낮습니까? 그렇지 않은 경우 공급자 이중화가 있습니까? | 라이선스 계약에 따라 월간 구독 또는 연간 구독 갱신 시 당사의 고객 클라우드 이용 약관을 검토해야 합니다. Atlassian의 법무 팀 및 조달 팀은 계약, SLA 및 공급업체 내부 정책을 검토하여 보안, 업무 가능 상태 및 기밀 유지와 관련된 위험을 관리합니다. Atlassian의 엔터프라이즈 위험 관리(ERM) 프로그램은 모든 위험 범주에 대한 가능성 및 영향을 포함하고 COSO 위험 모델에 정렬된 연간 위험 평가를 수행합니다. 위험 프로필에 따라 필요한 경우 기능적 위험 평가도 수행합니다. 위험 평가는 정책 갱신의 일부로 그리고 공급자와의 관계가 크게 바뀔 때마다 다시 검토됩니다. | |
| 6.02. (d) | 제3자 서비스 수준을 충족하고 유지하기 위해 어떤 조치를 취합니까? | Atlassian의 법무 팀 및 조달 팀은 계약, SLA 및 공급업체 내부 정책을 검토하여 보안, 업무 가능 상태 및 기밀 유지와 관련된 위험을 관리합니다. 위험 프로필에 따라 필요한 경우 기능적 위험 평가도 수행합니다. 위험 평가는 정책 갱신의 일부로 그리고 공급자와의 관계가 크게 바뀔 때마다 다시 검토됩니다. 이 프로세스는 Atlassian의 공급자 및 제3자 데이터 관리 정책에서 다루며 발췌 내용은 다음 페이지에서 확인할 수 있습니다: https://www.atlassian.com/trust/security/ismp-policies | |
| 6.02. (e) | 보안 정책 및 제어가 (계약상) 제3자 공급자에 적용되는지 클라우드 공급자가 확인할 수 있습니까? | 모든 시스템 및 프로젝트는 PII와 관련이 있는 경우 영향 평가를 거칩니다. Atlassian 제3자 계약에는 해당하는 경우 보안 및 개인정보 보호 조항이 포함됩니다. Atlassian의 신규 공급자는 계약서의 개인정보 보호 및 보안 정책에 동의해야 합니다. | |
운영 보안 | |||
| | 6.03. | 외부 공급자와의 모든 상업적 계약에는 모든 네트워크 서비스에 대한 서비스 수준이 포함될 것으로 예상됩니다. 하지만 최종 고객은 정의된 계약 외에도 공급자가 무단 공개를 완화하기 위해 적절한 제어를 적용하는지 확인해야 합니다. |
|
| | 6.03. (a) | 변경 관리 절차 및 정책을 자세히 설명합니다. 여기에는 변경으로 인한 위험을 다시 평가하고 최종 고객이 결과를 이용할 수 있는지 명확히 하는 프로세스도 포함해야 합니다. | Atlassian에는 COSO 위험 모델 및 ISO 31000에 부합하는 엔터프라이즈 위험 관리(ERM) 프로그램이 있습니다. ERM 프로그램에 따라 Atlassian 전체에 위험 관리 프레임워크와 방법론을 시행하고 위험 프로필을 기반으로 연간 위험 평가, 제품 환경에 대한 주기적 특정 위험 평가 및 필요에 따라 기능적 위험 평가를 수행합니다. 특히 Atlassian의 위험 관리 프레임워크는 위험 평가 활동을 완료하기 위한 표준, 프로세스, 역할 및 책임, 허용되는 위험의 범위 및 지침을 제공합니다. Atlassian의 위험 관리 프로세스와 관행은 유효하고 일관적이며 비교 가능한 결과를 산출하는 반복 가능한 위험 평가를 완료하도록 안내합니다. Atlassian이 수행하는 위험 평가에는 모든 위험 범주에 대한 가능성 및 영향, 그리고 내부적으로 설정된 위험 성향에 따른 모든 위험에 대한 처리 방식이 포함되어 있습니다. 위험 및 컴플라이언스 팀은 ERM 프로그램의 모든 단계에서 관련 이해 관계자와 소통하고 적절한 SME와 상의합니다.Atlassian 위험 관리 프로세스에서 역할을 맡은 직원은 자신의 책임 및 직무 수행에 대해 적절히 인식하고 있으며 교육을 받았습니다. 모든 위험은 자체 Jira 도구를 사용하여 추적 및 관리하며 관련 처리 계획 및 프로젝트에 대한 소유권은 관리 수준에 있습니다. 자세한 내용은 https://www.atlassian.com/trust/security/security-management-program 또는 https://www.atlassian.com/trust/compliance/risk-management-program을 참조하세요. |
| | 6.03. (b) | 원격 액세스 정책을 정의합니다. | 원격 액세스 요구 사항은 액세스 관리 정책 및 관련 표준에 정의됩니다. 고객 데이터는 지원 또는 마이그레이션 목적으로 유효한 고객 지원 티켓과 함께 직원 워크스테이션에 복제될 수 있습니다. 엄격한 방화벽 규칙이 마련되어 있으므로 프로덕션 환경에 대한 액세스는 VPN 네트워크 및 인증된 시스템으로 제한됩니다. VPN 액세스에는 다단계 인증이 필요합니다. |
| | 6.03. (c) | 공급자가 정보 시스템에 대해 문서화된 운영 절차를 유지합니까? | Atlassian의 운영 보안 기본 원칙에는 표준 운영 절차 문서 개발이 포함됩니다. 또한 Atlassian은 tl:dr에 대한 각 개략적인 정책의 발췌문을 게시했으며 다음 페이지에서 확인할 수 있습니다: https://www.atlassian.com/trust/security/ismp-policies |
| | 6.03. (d) | 위험을 줄이기 위해 스테이징된 환경(예: 개발, 테스트 및 운영 환경)이 있으며 각각 분리되어 있습니까? | Atlassian은 프로덕션 이외의 환경에서 프로덕션 데이터를 사용하는 것을 금지하는 정보 보안 정책을 갖추고 있으며 여러 환경 간에 데이터 마이그레이션을 시도하면 변경 관리 프로세스를 통해 식별됩니다. 코드는 중앙 집중식 빌드 시스템에서 이동하여 단위 테스트를 먼저 진행합니다. 기능 브랜치 검증을 시작하여 추가적인 테스트 자동화와 PM, Dev, QA의 게이트 검토를 거칩니다. 그런 다음 UAT, 보안 및 성능 검증으로 이동합니다. 개발자는 코드를 프로덕션으로 직접 승격할 수 없습니다. 자세한 내용은 다음 페이지에서 확인할 수 있습니다: https://www.atlassian.com/trust/security/security-practices#managing-changes-in-our-environment |
| | 6.03. (e) | 최종 고객의 애플리케이션 및 정보를 호스팅하는 시스템을 보호하는 데 사용하는 호스트 및 네트워크 제어를 정의합니다. 여기에는 외부 표준(예: ISO 27001/2)에 대한 인증 세부 정보가 포함되어야 합니다. | Atlassian 네트워크 엔지니어링 팀은 Cloud와 사무실 방화벽에 내장된 IPS 기술을 사용하며 Atlassian은 사무실 환경에 IDS 기술을 구현했습니다. DDoS 차단과 일부 웹 애플리케이션 방화벽 기능을 비롯한 네트워크 위협 방지는 AWS가 담당합니다. Atlassian 서비스의 모든 데이터는 HTTPS 또는 SMTPS를 통한 무단 공개나 수정을 방지하기 위해 TLS를 사용하여 전송 중에 암호화됩니다. |
| | 6.03. (f) | 악성 코드로부터 보호하는 데 사용할 제어를 지정합니다. | Atlassian은 Windows 및 Mac 기기를 위해 Crowdstrike Falcon(https://www.crowdstrike.com/falcon-platform/)을 구현했습니다. Linux 컴퓨터에서는 맬웨어 방지를 사용하지 않습니다. 맬웨어 방지는 취약성 관리 정책에 포함되어 있습니다. |
|
| 6.03. (g) | 승인된 모바일 코드 및 승인된 기능의 실행만 허용하도록(예: 특정 명령만 실행) 보안 구성이 배포되어 있습니까? | 모든 서버는 기본 이미지 및 중요 패키지 업데이트에서 일부 패키지를 제거하는 것을 포함하여 표준 운영 환경에 맞게 중앙 집중식 Puppet 구성 시스템을 사용하여 구성됩니다. 모든 서버 역할에는 기본적으로 수신 네트워킹 요청을 모두 거부하는 기능이 있으며 일부 포트는 기능을 위해 해당 포트에 액세스해야 하는 다른 서버 역할에만 열립니다. |
|
| 6.03. (h) | 백업에 대한 세부 정책 및 절차가 있습니까? 여기에는 이동식 미디어 관리 절차 및 더 이상 필요하지 않은 미디어를 안전하게 파기하는 방법이 포함되어야 합니다. (고객은 비즈니스 요구 사항에 따라 독립적인 백업 전략을 세우고 싶을 수도 있습니다. 특히 시간이 중요한 백업 액세스가 필요한 경우에 해당합니다.) | Atlassian은 종합적인 백업 프로그램을 운영하고 있습니다. 여기에는 시스템 복구 요구 사항에 따라 백업 조치가 설계된 내부 시스템이 포함됩니다. Atlassian Cloud 제품과 관련해서, 특히 고객 및 애플리케이션 데이터에 대한 광범위한 백업 조치도 마련되어 있습니다. Atlassian은 Amazon RDS(관계형 데이터베이스 서비스)의 스냅샷 기능을 사용하여 각 RDS 인스턴스를 매일 자동으로 백업합니다. Amazon RDS 스냅샷은 특정 시점으로 복구를 포함하여 30일 동안 보관되며 AES-256 암호화를 사용하여 암호화합니다. 백업 데이터는 오프사이트에 저장되지 않지만 특정 AWS 리전의 여러 데이터 센터에 복제됩니다. Atlassian은 분기별 백업 테스트도 수행합니다. Bitbucket의 경우 데이터는 다른 AWS 리전으로 복제되며 각 리전 내에서 매일 독립적인 백업이 수행됩니다. |
|
|
| 감사 로그는 문제 해결뿐만 아니라 조사가 필요한 인시던트 발생 시에도 사용됩니다. 이 목적에 따라 최종 고객은 관련 정보가 제공되는지에 대한 보증이 필요합니다. |
|
|
| 6.03. (i) | 공급자는 감사 로그 내에 어떤 정보가 기록되는지 자세히 설명할 수 있습니까?
| 각 시스템의 키 시스템 로그는 읽기 전용으로 로그를 확인할 수 있는 중앙 집중식 로그 플랫폼으로 전달됩니다. Atlassian 보안 팀은 보안 분석 플랫폼(Splunk)에 대한 알림을 만들고 침해 지표를 모니터링합니다. SRE 팀은 이 플랫폼을 사용하여 가용성 또는 성능 문제를 모니터링합니다. 로그는 핫 백업에서 30일간, 콜드 백업에서 365일간 보관됩니다. |
|
| 6.03. (j) | 감사 로그는 어떻게 검토됩니까? 기록된 이벤트에 대해 어떤 조치를 취합니까? | 각 시스템의 키 시스템 로그는 읽기 전용으로 로그를 확인할 수 있는 중앙 집중식 로그 플랫폼으로 전달됩니다. Atlassian 보안 팀은 보안 분석 플랫폼(Splunk)에 대한 알림을 만들고 침해 지표를 모니터링합니다. SRE 팀은 이 플랫폼을 사용하여 가용성 또는 성능 문제를 모니터링합니다. 로그는 핫 백업에서 30일간, 콜드 백업에서 365일간 보관됩니다. |
|
| 6.03. (k) | 시스템을 동기화하고 정확한 감사 로그 타임스탬프를 제공하는 데 사용되는 시간 소스는 무엇입니까? | Atlassian Cloud는 배포된 모든 인스턴스에 AWS Time Sync를 사용합니다. |
소프트웨어 보증 | |||
|
| 6.03.01. (a) | 운영 체제 및 사용되는 애플리케이션 소프트웨어의 무결성을 보호하는 데 사용되는 컨트롤을 정의하고, 준수하는 모든 표준을 포함하세요(예: OWASP, SANS Checklist, SAFECode). | Atlassian 보안 엔지니어 팀은 개발 주기 중에 제품의 모든 소스 코드를 지속적으로 롤링 검토합니다. 그리고 자동 기술과 수동 기술을 모두 사용합니다. 또한 Atlassian은 여러 선임 개발자 또는 개발자 리더가 마스터에 대한 모든 커밋을 검토하는 필수 이중 동료 검토 프로세스를 활용합니다. 애자일 워크플로를 통해 특히 Cloud 서비스의 취약성을 빠르게 식별하고 해결할 수 있습니다. |
|
| 6.03.01. (b) | 새 릴리스가 목적에 적합한지, 또는 위험(백도어, 트로이 목마 등)이 없는지 어떻게 검증합니까? 사용 전에 검토합니까? | Atlassian 변경 관리 프로세스는 기존 변경 프로세스와는 약간 다릅니다. Atlassian은 동료 검토 및 그린 빌드(PRGB) 컨트롤을 활용하여 코드 변경, 애플리케이션 변경 또는 인프라 변경 등 모든 변경 사항을 검토합니다. 동료 검토는 CD 도구에서 구성되며, 여기서는 중요한 브랜치에 풀리퀘스트마다 검토자를 여러 명 두도록 지정해야 합니다. 보통 검토자는 개발자 2명 및 팀 리더로 구성됩니다. 이 컨트롤에서 그린 빌드란 CI 단계의 통합이 지금까지 개발된 통합, 기능, 보안 및 기타 테스트를 모두 통과해야 한다는 뜻입니다. 이 테스트에 실패하면(레드 빌드), 코드가 병합되지 않으며 다시 검토하고 결함을 해결해야 합니다. 그린 빌드에 성공하면, 바이너리에 암호화 형식으로 서명이 이루어지고 Atlassian의 프로덕션 환경은 Atlassian의 키로 서명된 바이너리만 실행합니다. 테스트 프로세스에는 자동 평가 구성 요소 및 수동 평가 구성 요소가 모두 포함됩니다. Atlassian은 뛰어난 성과를 블로그에 게시합니다. Atlassian은 기존의 '품질 보증'이 아닌 '품질 지원'을 지향합니다. 자세한 내용은 https://www.atlassian.com/inside-atlassian/quality-assurance-vs-quality-assistance를 확인하세요. |
|
| 6.03.01. (c) | 애플리케이션을 안전하게 보호하기 위해 어떤 관행을 따릅니까? | Atlassian 애플리케이션은 동료 검토 및 그린 빌드(PRGB)를 의무화하며, 그 이후에는 애플리케이션 아티팩트에 암호화 형식으로 서명이 이루어지고 CI/CD 파이프라인에 의해 자동 배포됩니다. Atlassian에서 서명한 애플리케이션만 Atlassian의 프로덕션 환경에서 실행할 수 있습니다. |
|
| 6.03.01. (d) | 취약성이 없는지 확인하기 위해 소프트웨어 릴리스 침투 테스트가 실시됩니까? 취약성이 발견되면, 이를 해결 프로세스는 어떻게 됩니까? | Atlassian은 개발 수명 주기의 모든 단계에서 안전한 개발 관행을 수행합니다. 자세한 내용은 https://www.atlassian.com/trust/security/security-in-development를 참조하세요. |
패치 관리 |
|
|
|
|
| 6.03.02. (a) | 준수하는 패치 관리 절차를 자세히 설명할 수 있습니까? | Atlassian은 위협 및 취약성 관리 정책을 유지합니다. Atlassian에는 PMP(Policy Management Program)가 정의되어 있고, 여기에는 소유권, 가용성, 검토 주기와 Atlassian의 일반 목표가 개략적으로 설명되어 있습니다. 정책은 적어도 1년에 한 번 검토하며 고위 경영진의 승인을 받습니다. PMP에 대한 자세한 내용은 https://www.atlassian.com/trust/security/security-management-program에서 확인할 수 있습니다 |
|
| 6.03.02. (b) | 패치 관리 프로세스가 네트워크(인프라 구성 요소, 라우터, 스위치 등), 서버 운영 체제, 가상화 소프트웨어, 애플리케이션, 보안 하위 시스템(방화벽, 안티바이러스 게이트웨이, 침입 감지 시스템 등)과 같은 클라우드 제공 기술의 모든 계층을 보호하는지 확인할 수 있습니까? | 시스템 구성 변경은 프로덕션에 배포하기 전에 모든 변경 사항을 검토하는 자동화된 프로세스로 관리됩니다. Atlassian 서비스 운영 팀은 심각한 위험이 확인되는 즉시 패치를 배포할 수 있습니다. 패치를 얼마나 빨리 구현할지를 결정하는 내부 기준이 있으며, 모든 컴퓨터에 12시간 이내에 적용할 수 있습니다. 시스템 구성 파일 모니터링을 포함하는 IDS 시스템이 마련되어 있습니다. |
네트워크 아키텍처 컨트롤 | |||
|
| 6.03.03. (a) | DDoS(분산 서비스 거부) 공격을 완화하는 데 사용하는 컨트롤을 정의하세요.
| 네트워크 보안 요구 사항은 Atlassian의 PMP(Policy Management Program)에 따라 매년 검토되는 커뮤니케이션 보안 정책에 정의되어 있습니다. PMP에 대한 자세한 내용은 https://www.atlassian.com/trust/security/security-management-program을 참조하세요 |
|
| 6.03.03. (b) | 어떤 수준의 분리가 사용됩니까?
| Atlassian은 멀티 테넌트 SaaS 애플리케이션입니다. Atlassian Cloud Cloud의 핵심 기능인 멀티 테넌시는 여러 고객이 Jira 또는 Confluence 애플리케이션 계층의 한 인스턴스를 공유하면서 각 고객 테넌트의 애플리케이션 데이터를 분리할 수 있도록 지원합니다. Atlassian Cloud는 테넌트 컨텍스트 서비스(TCS)를 통해 이 작업을 수행합니다. 모든 사용자 ID는 정확히 하나의 테넌트와 연결되며, 이 테넌트는 Atlassian Cloud 애플리케이션에 액세스하는 데 사용됩니다. 자세한 내용은 https://www.atlassian.com/trust/security/security-practices#tenant-isolation을 참조하세요 |
|
| 6.03.03. (c) | 회사가 서비스 공급자와 분리된 경우나 그 반대의 경우에도 아키텍처가 클라우드에서 지속적인 운영을 지원합니까(예: 고객 LDAP 시스템에 대한 중요한 종속성이 있습니까)? | 비즈니스 연속성 및 재해 복구 정책과 비즈니스 연속성 및 재해 복구 계획을 갖추고 있으며 비즈니스 연속성/재해 복구 운영 위원회에서 이를 매년 검토합니다. 자세한 내용은 https://www.atlassian.com/trust/security/security-practices#faq-d323ae61-59b8-4ddb-96d4-30716b603e3e 및 https://www.atlassian.com/trust/security/data-management를 참조하세요. |
|
| 6.03.03. (d) | (PVLAN 및 VLAN 태깅 802.1q 아키텍처에서) 클라우드 제공자가 사용하는 가상 네트워크 인프라가 공급업체 및/또는 모범 사례별 표준에 따라 보호됩니까(예: MAC 스푸핑, ARP 포이즈닝 공격 등이 특정 보안 구성을 통해 차단됩니까)? | 네트워크 보안 요구 사항은 Atlassian의 PMP(Policy Management Program)에 따라 매년 검토되는 커뮤니케이션 보안 정책에 정의되어 있습니다. PMP에 대한 자세한 내용은 https://www.atlassian.com/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)를 실행할 수 있습니까? | Atlassian은 서비스형 소프트웨어(SaaS) 모델을 운영하므로 해당하지 않습니다. |
PaaS - 애플리케이션 보안 | |||
|
| 6.03.05. | 일반적으로 플랫폼 소프트웨어 스택의 보안은 PaaS 서비스 공급자의 책임입니다. 이 문서의 권장 사항은 PaaS 공급자가 PaaS 플랫폼을 설계하고 관리할 때 보안 원칙을 고려했음을 보여주는 유용한 근거로 활용할 수 있습니다. 대개 PaaS 공급자가 플랫폼을 정확히 어떻게 보호하는지에 대한 자세한 정보를 얻기 어렵지만, 다음 질문과 이 문서의 다른 섹션을 참고하면 공급자가 제공하는 기능을 평가하는 데 도움이 됩니다. |
|
|
| 6.03.05. (a) | 멀티 테넌트 애플리케이션을 각기 분리하는 방법에 대한 정보를 요청합니다. 억제 및 분리 조치에 대한 개략적인 설명이 필요합니다. | Atlassian은 서비스형 소프트웨어(SaaS) 모델을 운영하므로 해당하지 않습니다. |
|
| 6.03.05. (b) | 데이터에 대한 액세스가 엔터프라이즈 사용자 및 소유한 애플리케이션으로만 제한되도록 PaaS 공급자가 어떤 보증을 할 수 있습니까? | Atlassian은 서비스형 소프트웨어(SaaS) 모델을 운영하므로 해당하지 않습니다. |
|
| 6.03.05. (c) | 플랫폼 아키텍처는 클래식 '샌드박스'여야 합니다. 공급자가 PaaS 플랫폼 샌드박스에 새로운 버그 및 취약성이 있는지 모니터링하도록 보장합니까? | Atlassian은 서비스형 소프트웨어(SaaS) 모델을 운영하므로 해당하지 않습니다. |
|
| 6.03.05. (d) | PaaS 공급자는 일련의 보안 기능(고객 간에 재사용 가능)을 제공할 수 있어야 합니다. 여기에는 사용자 인증, Single Sign-On, 권한 부여(권한 관리) 및 SSL/TLS(API를 통해 제공)가 포함됩니까? | Atlassian은 서비스형 소프트웨어(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에서 Atlassian의 블로그 게시물을 확인하세요. |
|
| 6.03.06. (b) | SaaS 액세스 제어가 세분화되어 있고 조직 정책에 맞게 사용자 지정할 수 있습니까? | Enterprise 및 Premium Cloud 제품 고객은 중앙 집중식 관리 제어판에 액세스할 수 있습니다. 조직 관리자가 모든 제품 인스턴스의 사용자 액세스 및 권한을 관리할 수 있습니다. https://www.atlassian.com/blog/platform/cloud-enterprise-centralized-admin-controls에서 Atlassian의 블로그 게시물을 확인하세요. |
리소스 프로비저닝 | |||
|
| 6.03.07. (a) | 리소스 과부하(처리, 메모리, 스토리지, 네트워크)가 발생한 경우
| Atlassian은 6~12개월 전에 작업 수용량을 계획하며 개략적인 전략 계획은 36개월 전부터 시작합니다. |
|
| 6.03.07. (b) | 얼마나 확장할 수 있습니까? 공급자는 최소 기간 내에 사용 가능한 최대 리소스에 대한 보장을 제공합니까? | Atlassian은 6~12개월 전에 작업 수용량을 계획하며 개략적인 전략 계획은 36개월 전부터 시작합니다. |
|
| 6.03.07. (c) | 얼마나 빠르게 확장할 수 있습니까? 공급자는 최소 기간 내에 보조 리소스의 사용 가능 여부에 대한 보장을 제공합니까? | Atlassian은 6~12개월 전에 작업 수용량을 계획하며 개략적인 전략 계획은 36개월 전부터 시작합니다. |
|
| 6.03.07. (d) | 대규모 리소스 사용 추세(예: 계절적 영향)를 처리하기 위해 어떤 프로세스가 마련되어 있습니까? | Atlassian은 6~12개월 전에 작업 수용량을 계획하며 개략적인 전략 계획은 36개월 전부터 시작합니다. |
ID 및 액세스 관리 | |||
권한 부여 | |||
|
| 6.04.01. | 다음 제어 기능은 클라우드 공급자의 (자체적으로 제어하는) ID 및 액세스 관리 시스템에 적용됩니다. |
|
|
| 6.04.01. (a) | 전체 클라우드 시스템에 대한 시스템 전반의 권한을 가진 계정이 있습니까? 있는 경우 어떤 작업(읽기/쓰기/삭제)을 위한 것입니까? | Atlassian의 글로벌 지원 팀은 유지 관리 및 지원을 위해, 호스팅되는 모든 시스템 및 애플리케이션의 계정을 유지 관리합니다. 이 지원 팀은 애플리케이션 상태를 모니터링하고 시스템 또는 애플리케이션을 유지 관리하기 위한 목적으로만, 그리고 고객이 지원 시스템을 통해 요청하는 경우 호스팅되는 애플리케이션 및 데이터에 액세스합니다. |
|
| 6.04.01. (b) | 가장 높은 수준의 권한을 가진 계정은 어떻게 인증되고 관리됩니까? | Atlassian은 직무와 책임을 위해 이 액세스 권한이 필요한 직원을 제한합니다. 모든 티어 1 시스템은 Atlassian의 중앙 집중식 SSO(Single Sign-On) 및 디렉터리 솔루션을 통해 관리됩니다. 사용자에게는 HR 관리 시스템의 워크플로를 통해 프로필에 따른 적절한 액세스 권한이 부여됩니다. Atlassian은 MFA를 사용하여 모든 티어 1 시스템에 액세스합니다. Atlassian은 하이퍼바이저 관리 콘솔과 AWS API에 2단계 인증을 사용하고, 하이퍼바이저 관리 기능에 대한 모든 액세스를 일일 감사 보고서에 기록합니다. 하이퍼바이저 관리 콘솔과 AWS API에 대한 액세스 목록은 분기별로 검토됩니다. 또한 HR 시스템과 ID 저장소 간에 8시간 동기화를 유지합니다. |
|
| 6.04.01. (c) | 가장 중요한 의사 결정(예: 대규모 리소스 블록의 동시 프로비저닝 해제)은 어떻게 승인됩니까(단일 또는 이중, 그리고 조직 내 어떤 역할에 의해)? | Atlassian은 직무와 책임을 위해 이 액세스 권한이 필요한 직원을 제한합니다. 모든 티어 1 시스템은 Atlassian의 중앙 집중식 SSO(Single Sign-On) 및 디렉터리 솔루션을 통해 관리됩니다. 사용자에게는 HR 관리 시스템의 워크플로를 통해 프로필에 따른 적절한 액세스 권한이 부여됩니다. Atlassian은 MFA를 사용하여 모든 티어 1 시스템에 액세스합니다. Atlassian은 하이퍼바이저 관리 콘솔과 AWS API에 2단계 인증을 사용하고, 하이퍼바이저 관리 기능에 대한 모든 액세스를 일일 감사 보고서에 기록합니다. 하이퍼바이저 관리 콘솔과 AWS API에 대한 액세스 목록은 분기별로 검토됩니다. 또한 HR 시스템과 ID 저장소 간에 8시간 동기화를 유지합니다.Atlassian의 핵심 제품은 직무 분리 제어 기능을 갖추고 있으며 여기에는 다음이 포함되지만 이에 국한되지는 않습니다.
|
|
| 6.04.01. (d) | 같은 사용자에게 할당되는 높은 권한의 역할이 있습니까? 이렇게 할당하면 직무 분리 또는 최소 권한 규칙을 어기게 됩니까? | Atlassian은 직무와 책임을 위해 이 액세스 권한이 필요한 직원을 제한합니다. 모든 티어 1 시스템은 Atlassian의 중앙 집중식 SSO(Single Sign-On) 및 디렉터리 솔루션을 통해 관리됩니다. 사용자에게는 HR 관리 시스템의 워크플로를 통해 프로필에 따른 적절한 액세스 권한이 부여됩니다. Atlassian은 MFA를 사용하여 모든 티어 1 시스템에 액세스합니다. Atlassian은 하이퍼바이저 관리 콘솔과 AWS API에 2단계 인증을 사용하고, 하이퍼바이저 관리 기능에 대한 모든 액세스를 일일 감사 보고서에 기록합니다. 하이퍼바이저 관리 콘솔과 AWS API에 대한 액세스 목록은 분기별로 검토됩니다. 또한 HR 시스템과 ID 저장소 간에 8시간 동기화를 유지합니다.Atlassian의 핵심 제품은 직무 분리 제어 기능을 갖추고 있으며 여기에는 다음이 포함되지만 이에 국한되지는 않습니다.
|
|
| 6.04.01. (e) | 역할 기반 액세스 제어(RBAC)를 사용합니까? 최소 권한의 원칙을 준수합니까? | Atlassian은 HR 관리 시스템 및 액세스 프로비저닝 시스템을 연결하는 워크플로를 확립했습니다. Atlassian은 미리 정의된 사용자 프로필을 기반으로 하는 역할 기반 액세스 제어를 사용합니다. 데이터, 애플리케이션, 인프라 또는 네트워크 구성 요소에 액세스하려면 먼저 관리 팀이 모든 사용자 계정을 승인해야 합니다. |
|
| 6.04.01. (f) | 긴급 상황이 발생하면 특별 액세스를 허용하기 위해 관리자 권한 및 역할이 변경됩니까? 그런 경우 어떻게 변경됩니까? | Atlassian의 글로벌 지원 팀은 유지 관리 및 지원을 위해, 호스팅되는 모든 시스템 및 애플리케이션의 계정을 유지 관리합니다. 이 지원 팀은 애플리케이션 상태를 모니터링하고 시스템 또는 애플리케이션을 유지 관리하기 위한 목적으로만, 그리고 고객이 지원 시스템을 통해 요청하는 경우 호스팅되는 애플리케이션 및 데이터에 액세스합니다. |
|
| 6.04.01. (g) | 고객에게 '관리자' 역할이 있습니까? 예를 들어, 고객 관리자에게 새 사용자를 추가하는(하지만 기본 스토리지는 변경할 수 없는) 역할이 있습니까? | Atlassian은 고객 제품의 사용자 및 그룹을 관리하는 '조직 관리자' 역할을 고객에게 제공합니다. 자세한 내용은 https://support.atlassian.com/user-management/docs/give-users-admin-permissions/를 참조하세요 |
ID 프로비저닝 | |||
|
| 6.04.02. (a) | 등록 시 사용자 계정의 ID에 대해 어떤 확인이 이루어집니까? 따르는 표준이 있습니까? (예: 전자 정부 상호 운용성 프레임워크)
| 전 세계의 신규 Atlassian 직원은 신원 조사를 완료해야 합니다. 인수를 통해 새로 고용된 직원은 인수일 이후에 신원 조사를 실시합니다. 모든 신규 직원 및 독립 계약자에 대해 범죄 조사를 실시하며, 역할이나 직급에 따라 필요한 경우 학력 확인, 고용 확인 또는 신용 확인을 추가로 실시합니다. Atlassian은 고위 경영진과 회계 관련 직원들에 대해 완전한 신원 조사를 실시합니다. |
|
| 6.04.02. (b) | 자격 증명의 프로비저닝 해제를 위해 어떤 프로세스를 갖추고 있습니까? | 현재 Atlassian의 프로비저닝 해제 프로세스에는 고용, 계약 또는 합의 종료가 포함됩니다. 내부적으로 이전하는 사용자는 일반적으로 지속적인 참여 및 지원을 위해 액세스 권한을 유지합니다. 고객에 집중하는 대응력이 뛰어나고 유연한 팀을 제공하기 위해, 회사 가치에 따라 Atlassian은 액세스를 제한하여 대응 속도가 느려질 수 있도록 하는 것보다 무단 액세스 사용을 감지하는 데 중점을 두고 있습니다. |
|
| 6.04.02. (c) | 클라우드 시스템 전체에서 자격 증명이 동시에 프로비저닝 및 프로비저닝 해제됩니까? 아니면 지리적으로 분산된 여러 위치에서 자격 증명을 프로비저닝 해제할 때 위험이 있습니까? | Atlassian은 HR 관리 시스템 및 액세스 프로비저닝 시스템을 연결하는 워크플로를 확립했습니다. Atlassian은 미리 정의된 사용자 프로필을 기반으로 하는 역할 기반 액세스 제어를 사용합니다. 데이터, 애플리케이션, 인프라 또는 네트워크 구성 요소에 액세스하려면 먼저 관리 팀이 모든 사용자 계정을 승인해야 합니다. |
개인 데이터 관리 | |||
|
| 6.04.03. (a) | 사용자 디렉터리(예: AD, LDAP) 및 여기에 대한 액세스에는 어떤 데이터 스토리지 및 보호 제어 기능이 적용됩니까? | Atlassian은 정보 수명 주기 및 데이터 보안 정책에 따라 데이터를 분류 및 처리하고 이를 기반으로 컨트롤을 구현합니다. 자세한 내용은 https://www.atlassian.com/trust/security/security-practices를 참조하세요 |
|
| 6.04.03. (b) | 사용자 디렉터리 데이터를 상호 운용 가능한 형식으로 내보낼 수 있습니까? | 관리자는 관리자 패널에서 사용자 디렉터리를 내보낼 수 있습니다. Atlassian의 지원 사이트인 https://support.atlassian.com/organization-administration/docs/export-users-from-a-site/에서 가이드가 제공됩니다 |
|
| 6.04.03. (c) | 정보를 알아야 하는 경우에만 클라우드 공급자 내에서 고객 데이터에 액세스할 수 있습니까? | Atlassian은 직무와 책임을 위해 이 액세스 권한이 필요한 직원을 제한합니다. 모든 티어 1 시스템은 Atlassian의 중앙 집중식 SSO(Single Sign-On) 및 디렉터리 솔루션을 통해 관리됩니다. 사용자에게는 HR 관리 시스템의 워크플로를 통해 프로필에 따른 적절한 액세스 권한이 부여됩니다. Atlassian은 MFA를 사용하여 모든 티어 1 시스템에 액세스합니다. Atlassian은 하이퍼바이저 관리 콘솔과 AWS API에 2단계 인증을 사용하고, 하이퍼바이저 관리 기능에 대한 모든 액세스를 일일 감사 보고서에 기록합니다. 하이퍼바이저 관리 콘솔과 AWS API에 대한 액세스 목록은 분기별로 검토됩니다. 또한 HR 시스템과 ID 저장소 간에 8시간 동기화를 유지합니다.Atlassian의 핵심 제품은 직무 분리 제어 기능을 갖추고 있으며 여기에는 다음이 포함되지만 이에 국한되지는 않습니다.
|
키 관리 | |||
|
| 6.04.04. | 클라우드 공급자가 관리하는 키의 경우: |
|
|
| 6.04.04. (a) | 키를 읽고 쓸 수 있는 보안 컨트롤을 갖추고 있습니까? (예: 강력한 비밀번호 정책, 별도의 시스템에 저장된 키, 루트 인증서 키를 위한 하드웨어 보안 모듈(HSM), 스마트 카드 기반 인증, 스토리지에 대한 직접적인 보호 액세스, 짧은 키 수명 등) | Atlassian은 암호화 및 암호화 정책과 구현 가이드라인을 유지 관리합니다. 이 정책은 PMP(Policy Management Program)에 따라 매년 검토 및 업데이트됩니다. 자세한 내용은 https://www.atlassian.com/trust/security/security-management-program을 참조하세요. |
|
| 6.04.04. (b) | 해당 키로 데이터에 서명하고 암호화할 수 있는 보안 컨트롤을 갖추고 있습니까? | Atlassian은 Cloud 인프라에 대해 문서화된 키 관리 절차를 유지 관리합니다. S3에 저장된 Amazon 첨부 파일의 암호화 키는 Amazon KMS에서 관리합니다. 암호화, 키 관리 및 암호 해독 프로세스는 Amazon의 기존 감사 프로세스의 일부로 Amazon에서 내부적으로 정기적인 검사 및 확인을 진행합니다. KMS 내의 마스터 키는 만들어질 때 자동 교체를 통해 365일(매년)마다 마스터 키 자료를 생성합니다. |
|
| 6.04.04. (c) | 키 손상이 발생할 경우 절차가 마련되어 있습니까? 예: 키 철회 목록. | Atlassian은 Atlassian Cloud 인프라에 대해 문서화된 키 관리 절차를 유지 관리합니다. S3에 저장된 Amazon 첨부 파일의 암호화 키는 Amazon KMS에서 관리합니다. 암호화, 키 관리 및 암호 해독 프로세스는 Amazon의 기존 감사 프로세스의 일부로 Amazon에서 내부적으로 정기적인 검사 및 확인을 진행합니다. Atlassian에서 관리하는 키는 역할 또는 고용 상태가 바뀌면 교체됩니다. AWS KMS 서비스는 SOC 1, SOC 2, SOC 3을 준수합니다. 자세한 내용은 다음 페이지를 참조하세요: https://aws.amazon.com/kms/ |
|
| 6.04.04. (c) | 키 손상이 발생할 경우 절차가 마련되어 있습니까? 예: 키 철회 목록. | Atlassian은 Atlassian Cloud 인프라에 대해 문서화된 키 관리 절차를 유지 관리합니다. S3에 저장된 Amazon 첨부 파일의 암호화 키는 Amazon KMS에서 관리합니다. 암호화, 키 관리 및 암호 해독 프로세스는 Amazon의 기존 감사 프로세스의 일부로 Amazon에서 내부적으로 정기적인 검사 및 확인을 진행합니다. Atlassian에서 관리하는 키는 역할 또는 고용 상태가 바뀌면 교체됩니다. AWS KMS 서비스는 SOC 1, SOC 2, SOC 3을 준수합니다. 자세한 내용은 다음 페이지를 참조하세요: https://aws.amazon.com/kms/ |
|
| 6.04.04. (d) | 키 철회로 여러 사이트의 동시성 이슈를 해결할 수 있습니까? | Atlassian은 Atlassian Cloud 인프라에 대해 문서화된 키 관리 절차를 유지 관리합니다. S3에 저장된 Amazon 첨부 파일의 암호화 키는 Amazon KMS에서 관리합니다. 암호화, 키 관리 및 암호 해독 프로세스는 Amazon의 기존 감사 프로세스의 일부로 Amazon에서 내부적으로 정기적인 검사 및 확인을 진행합니다. Atlassian에서 관리하는 키는 역할 또는 고용 상태가 바뀌면 교체됩니다. AWS KMS 서비스는 SOC 1, SOC 2, SOC 3을 준수합니다. 자세한 내용은 다음 페이지를 참조하세요: https://aws.amazon.com/kms/ |
|
| 6.04.04. (e) | 고객 시스템 이미지는 보호됩니까, 아니면 암호화됩니까? | Atlassian은 업계 표준인 Transport Layer Security("TLS") 버전 1.2를 사용하여 256비트 고급 암호화 표준("AES") 암호화를 사용한 안전한 연결을 구축합니다. 사용자 데이터를 보관하는 서버는 전체 디스크, 업계 표준 AES 암호화를 사용합니다. 테넌트 데이터는 AWS RDS 또는 RDS 백업 내에서 암호화되며 장기간용 스토리지(S3) 및 모든 첨부 파일에서도 암호화됩니다. 자세한 내용은 다음 페이지를 참조하세요: https://www.atlassian.com/trust/security/security-practices#encryption-and-key-management |
암호화 | |||
| | 6.04.05. (a) | 암호화는 여러 곳에 사용할 수 있습니다. 어디에 사용됩니까?
| Atlassian은 암호화 및 암호화 정책과 구현 가이드라인을 유지 관리합니다. 이 정책은 PMP(Policy Management Program)에 따라 매년 검토 및 업데이트됩니다. 자세한 내용은 https://www.atlassian.com/trust/security/security-management-program 페이지를 참조하세요. |
|
| 6.04.05. (b) | 암호화해야 할 데이터 및 암호화하지 말아야 할 데이터에 관한 제대로 정의된 정책이 있습니까? | Atlassian은 암호화 및 암호화 정책과 구현 가이드라인을 유지 관리합니다. 이 정책은 PMP(Policy Management Program)에 따라 매년 검토 및 업데이트됩니다. 자세한 내용은 https://www.atlassian.com/trust/security/security-management-program 페이지를 참조하세요. |
|
| 6.04.05. (d) | 누가 액세스 키를 보유하고 있습니까? | Atlassian은 AWS KMS(Key Management Service)를 사용하여 키를 관리합니다. AWS는 기존 내부 유효성 검사 프로세스의 일부로 매년 정기적으로 암호화, 암호 해독 및 키 관리 프로세스를 검사하고 확인합니다. 각 키에 소유자를 할당하며 소유자는 키에 적절한 수준의 보안 컨트롤을 적용하는지 확인하는 업무를 담당합니다. |
|
| 6.04.05. (e) | 키는 어떻게 보호됩니까? | Atlassian은 AWS KMS(Key Management Service)를 사용하여 키를 관리합니다. AWS는 기존 내부 유효성 검사 프로세스의 일부로 매년 정기적으로 암호화, 암호 해독 및 키 관리 프로세스를 검사하고 확인합니다. 각 키에 소유자를 할당하며 소유자는 키에 적절한 수준의 보안 컨트롤을 적용하는지 확인하는 업무를 담당합니다. |
인증 | |||
|
| 6.04.06. (a) | 높은 보증이 필요한 작업에서는 어떤 형태의 인증이 사용됩니까? 여기에는 관리 인터페이스 로그인, 키 생성, 다중 사용자 계정 액세스, 방화벽 구성, 원격 액세스 등이 포함될 수 있습니다.
| Atlassian은 NIST Special Publication 800-63B에 설명된 가이드라인을 따릅니다. 다음 페이지를 참조하세요: https://pages.nist.gov/800-63-3/sp800-63b.html |
자격 증명 손상 또는 도용 | |||
| | 6.04.07. (a) | 이상 감지 기능(비정상적이고 잠재적으로 악의적일 수 있는 IP 트래픽 및 사용자 또는 지원팀 행동을 찾아내는 기능)을 제공합니까? 예: 로그인 실패 및 성공, 비정상적 시간대 및 다중 로그인에 대한 분석 등. | Atlassian Cloud 플랫폼은 방화벽을 통해 노출되는 표면이 거의 없습니다. Atlassian은 방화벽 규칙을 정기적으로 검토합니다. 사무실 및 Cloud 호스팅 환경에 IDS를 배포했습니다. Atlassian Cloud 플랫폼의 경우 보안 분석 플랫폼에 로그 전달 기능이 통합되었습니다. Cloud 플랫폼 컨테이너 수준에서는 인스턴스를 수정할 수 없으므로 파일 무결성이 유지됩니다. Atlassian 네트워크 엔지니어링 팀은 방화벽에 내장된 IPS 기술을 사용하며 Atlassian은 사무실 및 Cloud 환경에 IDS 기술을 구현했습니다. DDoS 기능은 인터넷 서비스 공급자/통신사에서 제공합니다. |
|
| 6.04.07. (b) | 고객의 자격 증명이 도난당한 경우(감지, 취소, 작업에 대한 증거) 어떤 프로비전이 마련되어 있습니까? | Atlassian Cloud 서비스의 컨텍스트에서 고객은 자신이 제어하는 서비스 사용자에 대한 액세스 관리의 일부 또는 전부를 책임져야 할 수 있습니다.
이 정책에 따라 Atlassian은 보안 인시던트 대응 계획을 유지 관리합니다. 보안 인시던트 대응 프로세스에 대한 자세한 내용은 다음 페이지를 참조하세요: https://www.atlassian.com/trust/security/security-incident-management |
Cloud 고객에게 제공되는 ID 및 액세스 관리 시스템 | |||
|
| 6.04.08. | 다음 질문은 Cloud 고객이 사용하고 제어할 수 있도록 클라우드 공급자가 제공하는 ID 및 액세스 관리 시스템에 적용됩니다. |
|
Cloud 고객에게 제공되는 ID 및 액세스 관리 시스템 | |||
|
| 6.04.08.01. (a) | 시스템에서 높은 보증(필요한 경우 OTP 시스템) 및 낮은 보증(예: 사용자 이름 및 비밀번호) 모두에 대해 상호 운용 가능한 페더레이션된 IDM 인프라를 허용합니까? | Atlassian Access는 Atlassian 제품(Confluence, Jira, Jira Align, Bitbucket 등) 전반에 걸쳐 ID 페더레이션 표준을 지원합니다. Atlassian Access는 Okta, Azure AD 또는 OneLogin을 사용하여 Active Directory를 Atlassian에 자동으로 동기화할 수 있습니다. 자세한 내용은 https://www.atlassian.com/enterprise/cloud/access 페이지를 참조하세요. 특정 제품 SSO 설정(일반 SAML v2.0, Google, Okta, OneLogin, PingIdentity, ADFS):
|
|
| 6.04.08.01. (b) | 클라우드 공급자는 타사 ID 공급자와 상호 운용이 가능합니까? | Atlassian 고객은 Atlassian에서 지원하는 경우 자신이 선택한 타사 ID 공급자를 이용할 수 있습니다. Atlassian 고객 지원팀 페이지에서는 이 기능을 비롯해 선택한 ID 공급자를 연결하는 방법을 자세히 설명합니다. 다음 페이지를 참조하세요: https://support.atlassian.com/provisioning-users/docs/supported-identity-providers/ |
|
| 6.04.08.01. (c) | single sign-on을 통합하는 기능이 있습니까? | Atlassian은 대부분의 제품 인증에 Google, Microsoft 및 Apple ID 사용을 지원합니다. 또한 Atlassian Access를 통해 Atlassian Cloud 서비스에 SAML도 지원합니다. https://www.atlassian.com/enterprise/cloud/access 페이지를 참조하세요. |
액세스 제어 | |||
|
| 6.04.08.02. (a) | 클라이언트 자격 증명 시스템에서 역할과 책임의 분리 및 여러 도메인(또는 여러 도메인, 역할 및 책임에 대한 단일 키)을 허용합니까? | Atlassian은 다중 테넌트 SaaS 애플리케이션입니다. Atlassian Cloud의 핵심 기능인 다중 테넌시는 여러 고객이 Jira 또는 Confluence 애플리케이션 계층의 한 인스턴스를 공유하면서 각 고객 테넌트의 애플리케이션 데이터를 분리할 수 있도록 지원합니다. Atlassian Cloud는 테넌트 컨텍스트 서비스(TCS)를 통해 이 작업을 수행합니다. 모든 사용자 ID는 정확히 하나의 테넌트와 연결되며 이 테넌트는 Atlassian Cloud 애플리케이션에 액세스하는 데 사용됩니다. 자세한 내용은 다음 페이지를 참조하세요: https://www.atlassian.com/trust/security/security-practices#tenant-isolation |
|
| 6.04.08.02. (b) | 고객 시스템 이미지에 대한 액세스를 관리하고 이미지에 인증 키 및 암호화 키가 포함되지 않도록 하려면 어떻게 해야 합니까? | Atlassian의 글로벌 지원 팀은 유지 관리 및 지원을 위해, 호스팅되는 모든 시스템 및 애플리케이션의 계정을 유지 관리합니다. 이 지원 팀은 애플리케이션 상태를 모니터링하고 시스템 또는 애플리케이션을 유지 관리하기 위한 목적으로만, 그리고 고객이 지원 시스템을 통해 요청하는 경우 호스팅되는 애플리케이션 및 데이터에 액세스합니다. |
인증 | | | |
|
| 6.04.08.03. (a) | 클라우드 공급자가 고객에게 어떻게 자신의 ID를 확인시켜 줍니까(즉, 상호 인증이 있습니까)?
| Atlassian은 상호 인증을 사용하여 고객에게 ID를 확인시켜 줍니다. Atlassian API 설명서는 https://developer.atlassian.com/cloud/에서 확인할 수 있습니다. Atlassian 서비스 인증 프로토콜(ASAP)은 JSON 웹 토큰(JWT)을 사용하여 구현되고 Atlassian이 신뢰하는 기관의 RSA 키를 사용하여 서명된 액세스 토큰을 활용하는 서비스 간 인증 프로토콜입니다. 자세히 알아보려면 Atlassian 서비스 인증 프로토콜을 참조하세요. Atlassian은 기존의 '서비스 계정'이라는 개념을 사용하지 않고 서비스 간 인증 및 승인을 사용합니다. |
|
| 6.04.08.03. (b) | Atlassian은 인증을 위한 페더레이션 메커니즘을 지원합니까? | Atlassian Access는 Atlassian 제품(Confluence, Jira, Jira Align, Bitbucket 등) 전반에 걸쳐 ID 페더레이션 표준을 지원합니다. Atlassian Access는 Okta, Azure AD 또는 OneLogin을 사용하여 Active Directory를 Atlassian에 자동으로 동기화할 수 있습니다. 자세한 내용은 https://www.atlassian.com/enterprise/cloud/access 페이지를 참조하세요. 특정 제품 SSO 설정(일반 SAML v2.0, Google, Okta, OneLogin, PingIdentity, ADFS):
|
자산 관리 | |||
|
| 6.05. | 공급자가 클라우드 공급자의 통제에 따라 하드웨어 및 소프트웨어(애플리케이션) 자산의 최신 목록을 유지하는지 확인하는 것이 중요합니다. 그러면 모든 시스템에 적절한 컨트롤이 적용되어 있는지, 시스템이 인프라의 백도어로 사용될 수 없는지 확인할 수 있습니다. |
|
|
| 6.05. (a) | 공급자는 모든 자산이 적절하게 관리되도록 모든 자산의 인벤토리를 만드는 자동화된 수단을 갖추고 있습니까? | Atlassian의 프로덕션 시스템은 클라우드 서비스 공급자를 통해 얻은 인프라에 위치합니다. 이러한 시스템은 서비스의 특성으로 인해 하드웨어 수준에서 추적되지 않습니다. 제품을 실행하는 기본 마이크로 서비스는 사용자 지정 '서비스' 데이터베이스에서 추적합니다. 이 데이터베이스는 서비스를 배포하면 자동으로 업데이트됩니다. |
|
| 6.05. (b) | 고객이 특정 기간 동안 사용한 자산의 목록이 있습니까? | Atlassian은 멀티 테넌트 SaaS 애플리케이션입니다. Atlassian Cloud Cloud의 핵심 기능인 멀티 테넌시는 여러 고객이 Jira 또는 Confluence 애플리케이션 계층의 한 인스턴스를 공유하면서 각 고객 테넌트의 애플리케이션 데이터를 분리할 수 있도록 지원합니다. Atlassian Cloud는 테넌트 컨텍스트 서비스(TCS)를 통해 이 작업을 수행합니다. 모든 사용자 ID는 정확히 하나의 테넌트와 연결되며, 이 테넌트는 Atlassian Cloud 애플리케이션에 액세스하는 데 사용됩니다. 자세한 내용은 https://www.atlassian.com/trust/security/security-practices#tenant-isolation을 참조하세요 |
|
|
| 다음 질문은 최종 고객이 추가 보호가 필요한 데이터(예: 민감한 것으로 간주되는 데이터)를 배포하는 경우 사용해야 합니다. |
|
|
| 6.05. (c) | 자산이 민감도 및 중요도를 기준으로 분류됩니까?
| Atlassian은 자산 및 서비스에 대해 4티어 등급을 유지하고 있으며, 가동 시간, 서비스 수준, 연속성 요구 사항은 티어별로 정해져 있습니다. 자세한 내용은 https://www.atlassian.com/trust/security/data-management를 참조하세요. |
데이터 및 서비스 이동성 | |||
|
| 6.06. | 공급업체 락인(lock-in)과 관련된 위험을 이해하려면 다음과 같은 질문을 고려해야 합니다. |
|
|
| 6.06. (a) | 클라우드에서 데이터를 내보내는 절차 및 API가 문서화되어 있습니까? | 고객 데이터는 웹 앱 및 API를 통해 내보낼 수 있습니다. 특정 제품에 대한 자세한 정보는 아래에 나와 있습니다.
|
|
| 6.06. (b) | 공급업체가 클라우드에 저장된 모든 데이터에 대해 상호 운용 가능한 내보내기 형식을 제공합니까? | Atlassian은 Atlassian 제품에서 고객 데이터가 호스팅되는 경우 고객의 데이터 내보내기 요청을 지원합니다. 제품 및 사용자 데이터를 내보낼 수 있는 강력한 데이터 이동성 및 데이터 관리 도구를 제공합니다. 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) | 사용자가 만든 애플리케이션을 표준 형식으로 내보내는 규정이 있습니까? | Atlassian은 서비스형 소프트웨어(SaaS) 모델을 운영하므로 해당하지 않습니다. |
|
| 6.06. (e) | 예를 들어 고객이 공급자를 변경하려는 경우 데이터를 다른 클라우드 공급자로 내보낼 수 있는지 테스트하는 프로세스가 있습니까? | Atlassian은 Atlassian 제품에서 고객 데이터가 호스팅되는 경우 고객의 데이터 내보내기 요청을 지원합니다. 제품 및 사용자 데이터를 내보낼 수 있는 강력한 데이터 이동성 및 데이터 관리 도구를 제공합니다. Atlassian Cloud 데이터 내보내기에 대한 자세한 내용은 https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/에 있는 가져오기 및 내보내기 설명서를 참조하세요. |
|
| 6.06. (f) | 고객이 직접 데이터를 추출하여 범용 형식이고 다른 클라우드 공급자로 마이그레이션할 수 있는지 확인할 수 있습니까? | Atlassian은 Atlassian 제품에서 고객 데이터가 호스팅되는 경우 고객의 데이터 내보내기 요청을 지원합니다. 제품 및 사용자 데이터를 내보낼 수 있는 강력한 데이터 이동성 및 데이터 관리 도구를 제공합니다. Atlassian Cloud 데이터 내보내기에 대한 자세한 내용은 https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/에 있는 가져오기 및 내보내기 설명서를 참조하세요. |
비즈니스 연속성 관리 | |||
|
| 6.07. | 연속성을 제공하는 것은 조직에 중요합니다. 시스템 가용성에 관한 최소 시간을 자세히 설명하는 서비스 수준 계약(SLA)을 설정할 수 있지만, 추가로 고려해야 할 사항이 남아 있습니다. |
|
|
| 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 계획이 분기별로 테스트되고 식별된 모든 문제를 해결합니다. 자세한 내용은 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) | 복원 프로세스와 관련된 종속성으로는 무엇이 있습니까? 공급자 및 아웃소싱 파트너를 포함합니다. | Atlassian에는 데이터 복원 작업을 위한 절차 및 로그가 있습니다. 개략적으로는 Atlassian의 내부 백업 표준과 비즈니스 연속성 및 재해 복구 정책에 포함되어 있습니다. 하지만 Atlassian 서비스마다 고객이 시작한 복원 및 Atlassian에서 시작한 복원에 대한 런북, 일정, 절차를 포함하는 다양한 내부 문서가 있습니다. |
|
| 6.07. (d) | 기본 사이트를 사용할 수 없게 되는 경우, 보조 사이트의 위치에 대한 최소 분리는 어떻게 됩니까? | 파트너 데이터 센터는 여러 컴플라이언스 인증을 유지합니다. 이러한 인증은 물리적 보안, 시스템 가용성, 네트워크 및 IP 백본 액세스, 고객 프로비저닝 및 문제 관리를 처리합니다. Data Center에 대한 액세스는 권한이 부여된 직원으로 제한되며, 생체 인식 신원 확인을 통해 확인합니다. 물리적 보안 조치에는 온프레미스 보안 요원, 폐쇄 회로 비디오 모니터링, 맨트랩, 추가 침입 보호 조치가 포함됩니다. AWS 물리적 보호 보증 정보는 http://aws.amazon.com/compliance/에서 확인할 수 있습니다. |
인시던트 관리와 대응 | |||
|
| 6.07.01. | 비즈니스 연속성 관리에는 인시던트 관리 및 대응이 포함됩니다. 이 프로세스의 목표는 예상치 못한 이벤트와 잠재적으로 중단을 유발하는 이벤트의 영향을 조직에서 수용 가능한 수준까지 억제하는 것입니다. 조직의 역량을 평가하여 정보 보안 인시던트의 발생 가능성을 최소화하거나 부정적인 영향을 줄이려면 클라우드 공급자에게 다음과 같은 질문을 해야 합니다. |
|
|
| 6.07.01. (a) | 공급자가 인시던트를 감지, 식별, 분석 및 대응하기 위한 공식적인 프로세스를 갖추고 있습니까? | Atlassian은 문서화된 보안 인시던트 대응 정책 및 계획을 갖추고 있으며, 그 핵심 원칙은 다음과 같습니다.
이 정책에 따라 Atlassian은 보안 인시던트 대응 계획을 유지합니다. 보안 인시던트 대응 프로세스에 대한 자세한 내용은 https://www.atlassian.com/trust/security/security-incident-management를 참조하세요 각 시스템의 키 시스템 로그는 읽기 전용으로 로그를 확인할 수 있는 중앙 집중식 로그 플랫폼으로 전달됩니다. Atlassian 보안 팀은 보안 분석 플랫폼(Splunk)에 대한 알림을 만들고 침해 지표를 모니터링합니다. SRE 팀은 이 플랫폼을 사용하여 가용성 또는 성능 문제를 모니터링합니다. 로그는 핫 백업에서 30일간, 콜드 백업에서 365일간 보관됩니다. 감지 프로그램에 대한 자세한 내용은 https://www.atlassian.com/trust/security/detections-program을 참조하세요 |
|
| 6.07.01. (b) | 인시던트 처리 프로세스가 효과적인지 확인하기 위해 이 프로세스를 리허설합니까? 또한 공급자는 리허설 중에 클라우드 공급자의 지원 조직에 있는 모든 구성원이 인시던트 처리 중(인시던트 도중 및 인시던트 발생 후 분석 과정 포함)에 프로세스 및 자신의 역할에 대해 파악하도록 보장합니까? | Atlassian Cloud 서비스의 경우 비즈니스 연속성 및 재해 복구 계획이 적어도 분기별로 테스트됩니다. 여러 리전의 가용성이 실시간으로 모니터링됩니다. 자동화된 리전 장애 조치 테스트는 사전 프로덕션 환경에서 매주 수행됩니다. 자동화된 구성 데이터 복원 테스트는 프로덕션 환경에서 매일 수행됩니다. 모든 Atlassian 서비스는 분기별로 사전 프로덕션 환경에서 가용성 영역 복원력 테스트를 수행합니다. 비즈니스 연속성 프로그램에 대한 자세한 내용은 https://www.atlassian.com/trust/security/security-practices#faq-d323ae61-59b8-4ddb-96d4-30716b603e3e를 참조하세요 |
|
| 6.07.01. (c) | 감지 기능은 어떻게 구성되어 있습니까?
| Atlassian Cloud 플랫폼은 방화벽을 통해 노출되는 표면이 거의 없습니다. Atlassian은 방화벽 규칙을 정기적으로 검토하며, 사무실과 Cloud 호스팅 환경에 IDS를 배포했습니다. Atlassian Cloud 플랫폼의 경우 보안 분석 플랫폼에 로그 전달 기능이 통합되었습니다. Cloud 플랫폼 컨테이너 수준에서는 인스턴스를 수정할 수 없기 때문에 파일 무결성이 유지됩니다. Atlassian 네트워크 엔지니어링 팀은 방화벽에 내장된 IPS 기술을 사용하며, Atlassian은 사무실 및 Cloud 환경에 IDS 기술을 구현했습니다. DDoS 기능은 인터넷 서비스 공급자/통신사에서 제공합니다. 감지 프로그램에 대한 자세한 내용은 https://www.atlassian.com/trust/security/detections-program을 참조하세요 각 시스템의 키 시스템 로그는 읽기 전용으로 로그를 확인할 수 있는 중앙 집중식 로그 플랫폼으로 전달됩니다. Atlassian 보안 팀은 보안 분석 플랫폼(Splunk)에 대한 알림을 만들고 침해 지표를 모니터링합니다. SRE 팀은 이 플랫폼을 사용하여 가용성 또는 성능 문제를 모니터링합니다. 로그는 핫 백업에서 30일간, 콜드 백업에서 365일간 보관됩니다. Atlassian은 중앙 집중식 로그 플랫폼에서 권한 있는 직원만 감사 로그를 보고 읽을 수 있도록 제한합니다. 또한 버그 바운티 프로그램, 고객 지원 포털, 정의된 보안 이메일 받은 편지함 및 전화번호를 포함하여 취약성 또는 인시던트를 인지할 수 있는 외부 보고 채널을 유지합니다. Atlassian은 고객이 무단 액세스 또는 악의적인 행동을 보고하도록 권장합니다. 자세한 내용은 https://www.atlassian.com/trust/security/security-incident-management 및 https://www.atlassian.com/trust/security/security-incident-responsibilities를 참조하세요. |
|
| 6.07.01. (d) | 심각도 수준은 어떻게 정의됩니까? | Atlassian은 보안 위험을 평가하고 발견된 취약점마다 우선 순위를 지정하기 위해 일반 취약점 점수 시스템(CVSS)을 사용합니다. 사용된 보안 수준은 다음을 포함하여 Atlassian이 자체 계산한 CVSS 점수를 기반으로 합니다.
심각도를 결정하는 점수 범위를 포함한 자세한 내용은 https://www.atlassian.com/trust/security/security-severity-levels를 참조하세요. |
|
| 6.07.01. (e) | 에스컬레이션 절차는 어떻게 정의됩니까? (있는 경우) 클라우드 고객은 언제 개입합니까? | Atlassian은 문서화된 보안 인시던트 대응 정책 및 계획을 갖추고 있으며, 그 핵심 원칙은 다음과 같습니다.
이 정책에 따라 Atlassian은 보안 인시던트 대응 계획을 유지합니다. 보안 인시던트 대응 프로세스에 대한 자세한 내용은 https://www.atlassian.com/trust/security/security-incident-management를 참조하세요 Atlassian은 데이터 침해 발생 시 즉시 통지를 받는 것이 얼마나 중요한지 잘 알고 있습니다. 따라서 Atlassian은 https://www.atlassian.com/trust/security/security-incident-management에 설명된 대로 보안 인시던트를 처리하기 위한 광범위한 교차 기능 팀 및 프로세스를 구축했습니다. Atlassian은 인시던트를 적시에 능동적으로 알리고 고객과 협업하여 필요한 완화 조치를 취한 확고한 기록을 보유하고 있습니다. Atlassian의 보안 인시던트 대응 팀이 인시던트가 진행됨에 따라 즉시 인시던트 분류 및 완화에 집중하는 것이 중요하기 때문에 Atlassian은 72시간 타임라인에 동의할 수 없습니다. 대신, Atlassian은 데이터 프로세서에 대한 GDPR 법적 요건에 따라 고객에게 '부당한 지연 없이' 알림을 제공하며, 이는 고객 대다수의 법적 요구를 충족합니다. 인시던트는 간단한 인시던트에서 복잡한 인시던트까지 범위가 다양하기 때문에 Atlassian은 법에 따라 필요한 사항은 제공할 수 있지만 '모든 상황에 맞는' 타임라인에는 동의할 수 없습니다. |
|
| 6.07.01. (f) | 인시던트가 문서화되고 증거가 수집되는 방법은 무엇입니까? | 취약성을 추적하고 수정하기 위한 Jira 티켓을 만들고, 취약성의 심각도 및 출처를 기준으로 SLO에 따라 기한을 할당합니다. 확인된 취약성 티켓을 시스템 소유자에게 발행하는 절차가 진행 중이며, 보안 관리 팀은 보고된 취약성을 검토하여 조치를 취합니다. |
|
| 6.07.01. (g) | 인증, 회계, 감사 외에 내부자의 악의적인 활동을 방지(또는 그 영향을 최소화)하기 위해 마련된 컨트롤은 무엇이 있습니까? | Atlassian은 사무실과 Cloud 호스팅 환경에 IDS를 배포했습니다. Atlassian Cloud 플랫폼의 보안 분석 플랫폼에는 로그 전달 기능이 통합되었습니다. 각 시스템의 키 시스템 로그는 읽기 전용으로 로그를 확인할 수 있는 중앙 집중식 로그 플랫폼으로 전달됩니다. Atlassian 보안 팀은 보안 분석 플랫폼(Splunk)에 대한 알림을 만들고 침해 지표를 모니터링합니다. 감지 프로그램에 대한 자세한 내용은 https://www.atlassian.com/trust/security/detections-program을 참조하세요 |
|
| 6.07.01. (h) | 공급자는 인시던트 메트릭 및 지표(예: 월별 탐지 또는 보고된 인시던트 수, 클라우드 공급자의 하청업체에 의해 발생한 인시던트 수 및 총 인시던트 수, 평균 대응 시간 및 해결 시간 등)를 수집합니까?
| 현재는 내부 메트릭을 공개하지 않지만, Statuspage에 심각도 0단계 또는 1단계 운영 인시던트에 대한 인시던트 발생 후 작업을 공유합니다. https://status.atlassian.com/을 참조하세요. |
|
| 6.07.01. (j) | 공급자는 재해 복구 및 비즈니스 연속성 계획을 얼마나 자주 테스트합니까? | Atlassian Cloud 서비스의 경우 비즈니스 연속성 및 재해 복구 계획이 적어도 분기별로 테스트됩니다. 여러 리전의 가용성이 실시간으로 모니터링됩니다. 자동화된 리전 장애 조치 테스트는 사전 프로덕션 환경에서 매주 수행됩니다. 자동화된 구성 데이터 복원 테스트는 프로덕션 환경에서 매일 수행됩니다. 모든 Atlassian 서비스는 분기별로 사전 프로덕션 환경에서 가용성 영역 복원력 테스트를 수행합니다. 비즈니스 연속성 프로그램에 대한 자세한 내용은 https://www.atlassian.com/trust/security/security-practices#faq-d323ae61-59b8-4ddb-96d4-30716b603e3e를 참조하세요 |
|
| 6.07.01. (k) | 공급자는 SLA 만족도에 대한 데이터를 수집합니까? | Atlassian은 모든 Cloud 인스턴스의 성능 및 가용성을 모니터링하지만, 현재는 공식적인 애플리케이션 가용성 SLA를 제공하지 않습니다. Atlassian의 지원 팀은 초기 응답 시간 SLA를 제공하며, 공식적인 지원 해결 SLA는 제공하지 않지만 내부 목표는 할당된 모든 케이스를 48시간 이내에 해결하는 것입니다. Atlassian은 최신 Cloud 시스템 상태 통계를 https:status.atlassian.com에 제공합니다. |
|
| 6.07.01. (l) | 공급자는 헬프 데스크 테스트를 실시합니까? 예:
| Atlassian은 신규 직원을 위한 온보딩 교육('1일 차') 중 하나로, 그리고 모든 직원에게 지속적으로 정보 보안 교육을 제공합니다. |
|
| 6.07.01. (m) | 공급자는 침투 테스트를 실시합니까? 얼마나 자주 실시합니까? 침투 테스트 중에 실제로 테스트하는 것은 무엇입니까? 예를 들어, 각 이미지의 보안 분리를 테스트하여 한 이미지를 다른 이미지로 '나누지' 못하고 호스트 인프라에 대한 액세스 권한도 얻을 수 없는지 확인합니까? 테스트 시 가상 이미지를 통해 클라우드 공급자의 관리 및 지원 시스템(예: 프로비저닝 및 관리자 액세스 제어 시스템)에 액세스할 수 있는지도 확인해야 합니다. | Atlassian은 내부 레드 팀을 두고 모든 인프라, Cloud 서비스, 인력에 대한 지속적인 침투 테스트 작업을 수행합니다. |
|
| 6.07.01. (n) | 공급자가 취약성 테스트를 실시합니까? 얼마나 자주 실시합니까? | Atlassian 보안 팀은 업계에서 인정한 취약성 스캐너를 사용하여 내부 및 외부 인프라의 네트워크 취약성 검사를 지속적으로 수행합니다. 취약성 관리 프로그램에 대한 자세한 내용은 https://www.atlassian.com/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 인프라에 동행 없이 (물리적으로) 액세스할 수 있습니까?
| Atlassian 사무실에는 물리적 출입구 모니터링을 포함한 내부 물리적 및 환경 보안 정책이 적용됩니다. Atlassian은 모든 내부 기술 운영 및 보안 정책의 발췌문을 다음 링크에 게시해 두었습니다. https://www.atlassian.com/trust/security/ismp-policies |
|
| 6.08. (a) (ii) | 액세스 권한은 얼마나 자주 검토됩니까?
| Atlassian은 적절한 메트릭을 사용하여 ISMS의 성과 및 효과를 평가합니다. Atlassian은 내부 및 외부 감사 검토를 통해 ATMS(Atlassian Trust Management System) 및 관련 제어의 성과를 모니터링합니다. Atlassian 규정 준수 팀은 내부/내부 준비 감사 일정 및 외부 감사 일정(감사 로드맵 페이지에 내부적으로 문서화됨)을 모두 관리합니다. 내부 감사는 Atlassian 전반에서 위험이 높은 영역에 초점을 맞추고 미리 정해진 일정에 따라, 그리고 위험 및 컴플라이언스 팀 및 내부 감사 팀 간에 합의된 Enterprise 감사 일정에 따라 정기적으로 실시합니다. 지금은 내부 메트릭을 공개하지 않습니다. ATMS는 독립적인 제3자에 의해 매년, 그리고 중대한 변경이 이루어진 후마다 평가됩니다. Atlassian은 각 주요 Cloud 서비스에 대해 SOC2, ISO27001 및 ISO7018 인증을 받았습니다. Atlassian은 또한 정기적인 운영 검토 회의를 통해 ATMS의 각 핵심 요소에 대한 구체적인 메트릭을 포함하여 요소를 모니터링합니다. 여기에는 ATMS: 컴플라이언스 상태 검토 페이지 및 ATMS 미팅 메모 페이지에 내부적으로 문서화되는 기타 미팅 및 ATMS에 대한 주간 컴플라이언스 상태 검토가 포함됩니다. 자세한 내용은 https://www.atlassian.com/trust/compliance 페이지를 참조하세요. |
|
| 6.08. (a) (iii) | 정기적으로 보안 위험을 평가하고 경계를 평가합니까?
| Atlassian은 적절한 메트릭을 사용하여 ISMS의 성과 및 효과를 평가합니다. Atlassian은 내부 및 외부 감사 검토를 통해 ATMS(Atlassian Trust Management System) 및 관련 제어의 성과를 모니터링합니다. Atlassian 규정 준수 팀은 내부/내부 준비 감사 일정 및 외부 감사 일정(감사 로드맵 페이지에 내부적으로 문서화됨)을 모두 관리합니다. 내부 감사는 Atlassian 전반에서 위험이 높은 영역에 초점을 맞추고 미리 정해진 일정에 따라, 그리고 위험 및 컴플라이언스 팀 및 내부 감사 팀 간에 합의된 Enterprise 감사 일정에 따라 정기적으로 실시합니다. 지금은 내부 메트릭을 공개하지 않습니다. ATMS는 독립적인 제3자에 의해 매년, 그리고 중대한 변경이 이루어진 후마다 평가됩니다. Atlassian은 각 주요 Cloud 서비스에 대해 SOC2, ISO27001 및 ISO7018 인증을 받았습니다. Atlassian은 또한 정기적인 운영 검토 회의를 통해 ATMS의 각 핵심 요소에 대한 구체적인 메트릭을 포함하여 요소를 모니터링합니다. 여기에는 ATMS: 컴플라이언스 상태 검토 페이지 및 ATMS 미팅 메모 페이지에 내부적으로 문서화되는 기타 미팅 및 ATMS에 대한 주간 컴플라이언스 상태 검토가 포함됩니다. 자세한 내용은 https://www.atlassian.com/trust/compliance 페이지를 참조하세요. |
|
| 6.08. (a) (iv) | 이웃 건물과 같은 것을 포함하여 정기적인 위험 평가를 수행합니까? | Atlassian은 적절한 메트릭을 사용하여 ISMS의 성과 및 효과를 평가합니다. Atlassian은 내부 및 외부 감사 검토를 통해 ATMS(Atlassian Trust Management System) 및 관련 제어의 성과를 모니터링합니다. Atlassian 규정 준수 팀은 내부/내부 준비 감사 일정 및 외부 감사 일정(감사 로드맵 페이지에 내부적으로 문서화됨)을 모두 관리합니다. 내부 감사는 Atlassian 전반에서 위험이 높은 영역에 초점을 맞추고 미리 정해진 일정에 따라, 그리고 위험 및 컴플라이언스 팀 및 내부 감사 팀 간에 합의된 Enterprise 감사 일정에 따라 정기적으로 실시합니다. 지금은 내부 메트릭을 공개하지 않습니다. ATMS는 독립적인 제3자에 의해 매년, 그리고 중대한 변경이 이루어진 후마다 평가됩니다. Atlassian은 각 주요 Cloud 서비스에 대해 SOC2, ISO27001 및 ISO7018 인증을 받았습니다. Atlassian은 또한 정기적인 운영 검토 회의를 통해 ATMS의 각 핵심 요소에 대한 구체적인 메트릭을 포함하여 요소를 모니터링합니다. 여기에는 ATMS: 컴플라이언스 상태 검토 페이지 및 ATMS 미팅 메모 페이지에 내부적으로 문서화되는 기타 미팅 및 ATMS에 대한 주간 컴플라이언스 상태 검토가 포함됩니다. 자세한 내용은 https://www.atlassian.com/trust/compliance 페이지를 참조하세요. |
|
| 6.08. (a) (v) | 보안 구역에 액세스하는 직원(제3자 포함)을 관리하거나 모니터링합니까? | Atlassian 사무실에는 물리적 출입구 모니터링을 포함한 내부 물리적 및 환경 보안 정책이 적용됩니다. Atlassian은 모든 내부 기술 운영 및 보안 정책의 발췌문을 다음 링크에 게시해 두었습니다: https://www.atlassian.com/trust/security/ismp-policies |
|
| 6.08. (a) (vi) | 장비의 적재, 하역 및 설치에 대해 어떤 정책 또는 절차를 갖추고 있습니까? | Atlassian 사무실 시설에서 하역장은 작업 구역과 격리되어 있으며 CCTV 및 건물 직원이 항상 모니터링합니다. Atlassian의 데이터 센터 호스팅 파트너는 물리적 보안을 관리하고 Atlassian은 파트너의 컴플라이언스 인증을 통해 제어가 효과적인지 검증합니다. |
|
| 6.08. (a) (vii) | 배송물은 설치 전에 위험 여부를 검사합니까? | Atlassian 사무실 시설에서 하역장은 작업 구역과 격리되어 있으며 CCTV 및 건물 직원이 항상 모니터링합니다. Atlassian의 데이터 센터 호스팅 파트너는 물리적 보안을 관리하고 Atlassian은 파트너의 컴플라이언스 인증을 통해 제어가 효과적인지 검증합니다. |
|
| 6.08. (a) (viii) | 데이터 센터에 있는 품목의 최신 실제 인벤토리가 있습니까? | Atlassian의 자산 관리 정책의 발췌문은 https://www.atlassian.com/trust/security/ismp-policies에서 확인할 수 있습니다. Atlassian은 자산 소유주와 더불어 모든 프로덕션 자산의 인벤토리를 유지합니다. Atlassian의 시스템은 모두 AWS 기반 데이터 센터에 있습니다. Atlassian의 AWS 시스템은 서비스의 특성으로 인해 하드웨어 수준에서 추적되지 않습니다. |
|
| 6.08. (a) (ix) | 네트워크 케이블이 공공 액세스 구역을 통과합니까?
| Atlassian 사무실에는 물리적 출입구 모니터링을 포함한 내부 물리적 및 환경 보안 정책이 적용됩니다. Atlassian은 모든 내부 기술 운영 및 보안 정책의 발췌문을 다음 링크에 게시해 두었습니다: https://www.atlassian.com/trust/security/ismp-policies |
|
| 6.08. (a) (x) | 무단 장비를 찾기 위해 정기적으로 건물을 조사합니까? | Atlassian의 자산 관리 정책의 발췌문은 https://www.atlassian.com/trust/security/ismp-policies에서 확인할 수 있습니다. Atlassian은 자산 소유주와 더불어 모든 프로덕션 자산의 인벤토리를 유지합니다. Atlassian의 시스템은 모두 AWS 기반 데이터 센터에 있습니다. Atlassian의 AWS 시스템은 서비스의 특성으로 인해 하드웨어 수준에서 추적되지 않습니다. |
|
| 6.08. (a) (xi) | 현장에 없는 장비가 있습니까?
| Atlassian의 자산 관리 정책의 발췌문은 https://www.atlassian.com/trust/security/ismp-policies에서 확인할 수 있습니다. Atlassian은 자산 소유주와 더불어 모든 프로덕션 자산의 인벤토리를 유지합니다. Atlassian의 시스템은 모두 AWS 기반 데이터 센터에 있습니다. Atlassian의 AWS 시스템은 서비스의 특성으로 인해 하드웨어 수준에서 추적되지 않습니다. |
|
| 6.08. (a) (xii) | 직원은 데이터 센터에 대한 액세스를 제공할 수 있는 휴대용 장비(예: 노트북, 스마트폰)를 사용할 수 있습니까?
| 파트너 데이터 센터는 여러 컴플라이언스 인증을 유지합니다. 이 인증은 물리적 보안, 시스템 가용성, 네트워크 및 IP 백본 액세스, 고객 프로비저닝 및 문제 관리를 처리합니다. 데이터 센터에 대한 액세스는 권한이 부여된 직원으로 제한되며 생체 인식 신원 확인을 통해 확인합니다. 물리적 보안 조치에는 온프레미스 보안 요원, 폐쇄 회로 비디오 모니터링, 맨트랩 및 추가 침입 보호 조치가 포함됩니다. AWS 물리적 보호 보증 정보는 다음 링크에서 확인할 수 있습니다: http://aws.amazon.com/compliance/ |
|
| 6.08. (a) (xiii) | 액세스 카드를 관리하기 위해 어떤 조치를 갖추고 있습니까? | Atlassian 사무실에는 물리적 출입구 모니터링을 포함한 내부 물리적 및 환경 보안 정책이 적용됩니다. Atlassian은 모든 내부 기술 운영 및 보안 정책의 발췌문을 다음 링크에 게시해 두었습니다: https://www.atlassian.com/trust/security/ismp-policies |
|
| 6.08. (a) (xiv) | 오래된 미디어 또는 시스템을 폐기해야 할 때를 위해 어떤 프로세스 또는 절차가 마련되어 있습니까?
| 직장 기술 팀이 이 프로세스를 처리하고 장비는 적절하게 완전 삭제 및 소자됩니다. Atlassian은 Cloud 제품 및 서비스를 지원하는 물리적 미디어를 관리하지 않습니다. |
|
| 6.08. (a) (xv) | 한 현장에서 다른 현장으로 장비를 이동할 때 어떤 승인 프로세스가 마련되어 있습니까?
| Atlassian의 데이터 센터 호스팅 파트너(AWS)는 물리적 보안을 관리하며 Atlassian은 AWS의 SOC2를 통해 제어가 효과적인지 검증합니다. |
|
| 6.08. (a) (xvi) | 무단 장비 제거를 모니터링하기 위해 장비에 대해 감사를 얼마나 자주 수행합니까? | Atlassian의 데이터 센터 호스팅 파트너(AWS)는 물리적 보안을 관리하며 Atlassian은 AWS의 SOC2를 통해 제어가 효과적인지 검증합니다. |
|
| 6.08. (a) (xvii) | 환경이 적절한 법률 및 규제 요구 사항을 준수하는지 확인하기 위해 얼마나 자주 검사합니까? | Atlassian 법무 팀 및 컴플라이언스 팀에서는 규제 의무를 모니터링합니다. 법률 프로그램에 대해서는 https://www.atlassian.com/legal/ 페이지를 참조하세요. 컴플라이언스 프로그램에 관한 자세한 내용은 다음 페이지에서 확인할 수 있습니다: https://www.atlassian.com/trust/compliance |
환경 관리 | |||
|
| 6.09. (a) | 환경 문제로 인해 서비스가 중단되지 않도록 하기 위해 어떤 정책 또는 절차를 갖추고 있습니까? | Atlassian 사무실에는 물리적 출입구 모니터링을 포함한 내부 물리적 및 환경 보안 정책이 적용됩니다. |
|
| 6.09. (b) | 화재, 홍수, 지진 등으로 인한 피해를 방지하기 위해 어떤 방법을 사용합니까?
| Atlassian은 파트너 데이터 호스팅 파트너의 도움을 받아 데이터 센터 보안 및 환경 제어를 검증합니다. AWS의 경우 https://aws.amazon.com/compliance/programs 페이지를 참조하세요. |
|
| 6.09. (c) | 데이터 센터의 온도 및 습도를 모니터링합니까?
| Atlassian은 파트너 데이터 호스팅 파트너의 도움을 받아 데이터 센터 보안 및 환경 제어를 검증합니다. AWS의 경우 https://aws.amazon.com/compliance/programs 페이지를 참조하세요. |
|
| 6.09. (d) | 번개로부터 건물을 보호합니까?
| Atlassian은 파트너 데이터 호스팅 파트너의 도움을 받아 데이터 센터 보안 및 환경 제어를 검증합니다. AWS의 경우 https://aws.amazon.com/compliance/programs 페이지를 참조하세요. |
|
| 6.09. (e) | 정전 시 사용할 수 있는 독립형 발전기가 있습니까?
| Atlassian은 파트너 데이터 호스팅 파트너의 도움을 받아 데이터 센터 보안 및 환경 제어를 검증합니다. AWS의 경우 https://aws.amazon.com/compliance/programs 페이지를 참조하세요. |
|
| 6.09. (f) | 모든 유틸리티(전기, 수도 등)가 환경을 지원할 수 있습니까?
| Atlassian은 파트너 데이터 호스팅 파트너의 도움을 받아 데이터 센터 보안 및 환경 제어를 검증합니다. AWS의 경우 https://aws.amazon.com/compliance/programs 페이지를 참조하세요. |
|
| 6.09. (g) | 에어컨이 환경을 지원할 수 있습니까?
| Atlassian은 파트너 데이터 호스팅 파트너의 도움을 받아 데이터 센터 보안 및 환경 제어를 검증합니다. AWS의 경우 https://aws.amazon.com/compliance/programs 페이지를 참조하세요. |
|
| 6.09. (h) | 제조업체에서 권장하는 유지 관리 일정을 따릅니까? | Atlassian은 파트너 데이터 호스팅 파트너의 도움을 받아 데이터 센터 보안 및 환경 제어를 검증합니다. AWS의 경우 https://aws.amazon.com/compliance/programs 페이지를 참조하세요. |
|
| 6.09. (i) | 권한이 부여된 유지 관리 또는 수리 직원만 현장 출입을 허용합니까?
| 사무실 시설에 대한 물리적 액세스는 전자 배지 액세스, 방문자 필수 로그인이 적용되는 업무 시간 리셉션 및 모든 건물 출입구의 CCTV를 통해 보호됩니다. 하역장은 CCTV 및 빌딩 직원이 항상 모니터링합니다. Atlassian의 데이터 센터 호스팅 파트너는 물리적 보안을 관리하고 Atlassian은 파트너의 컴플라이언스 인증을 통해 제어가 효과적인지 검증합니다. |
|
| 6.09. (j) | 장비를 수리하려고 보낼 경우 먼저 장비에서 데이터를 정리합니까?
| 직장 기술 팀이 이 프로세스를 처리하고 장비는 적절하게 완전 삭제 및 소자됩니다. Atlassian은 Cloud 제품 및 서비스를 지원하는 물리적 미디어를 관리하지 않습니다. |
법적 요구 사항 | |||
|
| 6.10. | 클라우드 공급자 서비스의 고객 및 잠재 고객은 규제 프레임워크 준수에 대한 국가적 의무 및 초국가적 의무를 고려하고 그 의무를 적절하게 준수하고 있는지 확인해야 합니다. |
|
|
| 6.10. (a) | 클라우드 공급자가 있는 국가는 어디입니까? | Atlassian은 시드니, 암스테르담, 앙카라, 보스턴, 벵갈루루, 샌프란시스코, 마운틴 뷰, 텍사스주 오스틴, 뉴욕, 마닐라, 그단스크 및 일본을 비롯하여 8개국에 사무소 12곳을 두고 있습니다. 자세한 내용은 https://www.atlassian.com/company/contact 페이지를 참조하세요. |
|
| 6.10. (b) | 클라우드 공급자의 인프라가 같은 나라에 있습니까? 아니면 다른 나라에 있습니까? | Atlassian Cloud의 경우 현재 중복 AWS 가용 영역 내에서 호스팅됩니다. 특정 리전에 관한 자세한 내용은 https://www.atlassian.com/trust/reliability/infrastructure 페이지를 참조하세요. |
|
| 6.10. (c) | 클라우드 공급자는 인프라가 클라우드 공급자 외부에 있는 다른 회사를 이용합니까? | Atlassian Cloud 제품 및 데이터는 업계 최고의 클라우드 공급자 AWS(Amazon Web Services)에서 호스팅합니다. Atlassian 제품은 PaaS(서비스형 플랫폼) 환경에서 실행되며 이 환경은 2개의 기본 인프라, 즉 Micros 환경 및 Micros 이외의 환경으로 나뉩니다. Micros 플랫폼에서 실행하는 제품에는 Jira, Confluence, Statuspage, Access 및 Bitbucket이 있으며 Micros 이외의 환경에서 실행하는 제품에는 Opsgenie 및 Trello가 있습니다. |
|
| 6.10. (d) | 데이터가 물리적으로 어디에 저장됩니까? | Atlassian은 미국 동부, 미국 서부, 아일랜드, 프랑크푸르트, 싱가포르 및 시드니 리전(Confluence 및 Jira)에서 AWS(Amazon Web Services)를 사용합니다.
데이터 보존에 대한 자세한 내용은 https://support.atlassian.com/security-and-access-policies/docs/understand-data-residency/ 페이지를 참조하세요. |
|
| 6.10. (e) | 계약 조건 및 데이터에 대한 관할권이 나뉩니까? | Atlassian 고객 계약의 기본 준거법은 캘리포니아 법입니다. 자세한 내용은 엔터프라이즈 영업 팀에 문의하세요. |
|
| 6.10. (f) | 클라우드 공급자의 서비스 중에 하도급을 주는 서비스가 있습니까? | Atlassian은 타사 하위 계약업체와 협력하여 웹 사이트, 애플리케이션 개발, 호스팅, 유지 관리, 백업, 스토리지, 가상 인프라, 결제 처리, 분석 및 기타 서비스를 제공합니다. 서비스 공급자는 Atlassian에 서비스를 제공할 목적으로 PII에 액세스하거나 PII를 처리할 수 있습니다. |
|
| 6.10. (g) | 클라우드 공급자의 서비스 중에 아웃소싱되는 게 있습니까? | Atlassian은 타사 공급업체를 참여시킬 경우 그 참여가 어떤 식으로든 고객 또는 고객의 데이터를 위태롭게 하지 않도록 주의를 기울입니다. Atlassian의 법률 및 조달 부서는 계약, SLA 및 공급업체 내부 정책을 검토하여 공급업체가 보안, 가용성 및 기밀 유지 요구 사항의 충족 여부를 결정합니다. 자세한 내용은 https://www.atlassian.com/trust/security/security-practices#supplier-risk-management 페이지를 참조하세요. |
|
| 6.10. (h) | 고객 및 고객의 고객이 제공한 데이터는 어떻게 수집, 처리 및 전송됩니까? | Atlassian은 정보 수집 목적 또는 이후에 개인이 승인한 목적에 부합하는 방식으로, 특히 Atlassian 외부 개인 정보 보호 정책에 따라 정보를 처리합니다. |
|
| 6.10. (i) | 계약 해지 시 클라우드 공급자에게 전송된 데이터는 어떻게 됩니까? | Atlassian은 여러 유형의 데이터를 유지해야 하는 기간을 지정하는 데이터 보존 및 파기 표준을 준수합니다. Atlassian은 Atlassian 데이터 보안 및 정보 수명 주기 정책에 따라 데이터를 분류하고 이것을 기반으로 컨트롤을 구현합니다. Atlassian 계약이 종료된 고객 데이터의 경우 고객 팀에 속한 고객 데이터가 라이브 프로덕션 데이터베이스에서 제거되고 Atlassian에 직접 업로드된 모든 첨부 파일이 14일 이내에 제거됩니다. 팀 데이터는 암호화된 백업 상태로 남겨지며 이 백업이 90일 백업 보존 기간을 초과하면 Atlassian 데이터 보존 정책에 따라 폐기됩니다. 데이터 삭제를 요청한 후 90일 이내에 데이터베이스 복원이 필요한 경우 운영 팀은 라이브 프로덕션 시스템이 완전히 복원된 후 최대한 빨리 데이터를 다시 삭제합니다. 자세한 내용은 다음 페이지를 참조하세요: https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/ |