| 원칙 1: 전송 중 데이터 보호 |
| 1.1 암호화 | Atlassian은 기본 공급업체 설정을 수정하는 것을 포함하여 내부 무선 네트워크에서 암호화를 유지합니다. Atlassian의 작업 공간 기술 팀은 WPA2-AES 인증과 PEAP-EAP-MSCHAPv2 암호화를 활용하여 무선 네트워크를 보호합니다. Atlassian은 내부 ID 저장소를 이용하여 802.1x를 통해 무선 네트워크를 인증합니다. Atlassian은 정기적으로 불량 무선 액세스 포인트를 검사하고 발견된 불량 액세스 포인트의 목록을 유지 관리합니다.
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를 참조하세요 | Atlassian의 보안 및 데이터 개인 정보 보호 정책
데이터 암호화 | Atlassian Trust Center 데이터
암호화 | Atlassian Cloud 아키텍처 및 운영 관행 |
| 1.2 네트워크 보호 | Atlassian의 Policy Management Program(PMP)에는 네트워크 관리에 대한 책임을 명시하는 통신 보안 정책이 포함되어 있습니다.
네트워크 액세스를 위해 Atlassian은 정의된 프로필에 따른 역할 기반 액세스 제어를 실행하는 중앙 집중식 LDAP 지원 디렉터리를 사용합니다. 사용자에게는 Atlassian의 HR 관리 시스템의 워크플로를 통해 프로필에 따른 적절한 액세스 권한이 부여됩니다. 내부 프로덕션 네트워크 액세스 규칙은 AWS VPC 환경 내에서 명시적으로 지정된 보안 그룹을 사용하여 유지 관리됩니다.
Atlassian의 작업 공간 기술 팀은 WPA2-AES 인증과 PEAP-EAP-MSCHAPv2 암호화를 활용하여 무선 네트워크를 보호합니다. Atlassian은 내부 ID 저장소를 이용하여 802.1x를 통해 무선 네트워크를 인증합니다.Atlassian 네트워크 엔지니어링 팀은 Cloud와 사무실 방화벽에 내장된 IPS 기술을 사용하며, Atlassian은 사무실 환경에 IDS 기술을 구현했습니다. DDoS 차단과 일부 웹 애플리케이션 방화벽 기능을 비롯한 네트워크 위협 방지는 AWS가 담당합니다.
Atlassian 서비스의 모든 데이터는 HTTPS나 SMTPS를 통한 무단 공개나 수정을 방지하기 위해 TLS를 사용하여 전송 중에 암호화됩니다. Atlassian은 TLS를 통해 강력한 암호 사용을 적용합니다. | Atlassian의 보안 및 데이터 개인 정보 보호 정책
네트워크 인프라에 보안 기능 구축 | Atlassian Trust Center |
| 1.3 인증 | Atlassian은 직무와 책임을 위해 이 액세스 권한이 필요한 직원을 제한합니다. 모든 티어 1 시스템은 Atlassian의 중앙 집중식 SSO(single sign-on) 및 디렉터리 솔루션을 통해 관리됩니다. 사용자에게는 Atlassian의 HR 관리 시스템의 워크플로를 통해 프로필에 따른 적절한 액세스 권한이 부여됩니다. Atlassian은 MFA를 사용하여 모든 티어 1 시스템에 액세스합니다. Atlassian은 하이퍼바이저 관리 콘솔 및 AWS API에 2단계 인증을 사용하고 하이퍼바이저 관리 기능에 대한 모든 액세스를 일일 감사 보고서에 기록합니다. 하이퍼바이저 관리 콘솔 및 AWS API에 대한 액세스 목록은 분기별로 검토됩니다. 또한 HR 시스템과 ID 저장소 간에 8시간 동기화를 유지합니다.
Atlassian은 대부분의 제품 인증에 Google, Microsoft 및 Apple ID 사용을 지원합니다. 또한 Atlassian Access를 통한 Atlassian Cloud 서비스에 SAML도 지원합니다. https://www.atlassian.com/enterprise/cloud/access를 참조하세요 | Atlassian의 보안 및 데이터 프라이버시 정책
제로 트러스트를 통한 네트워크 액세스 보안 | Atlassian Trust Center 서비스
인증 및 권한 부여 | Atlassian Cloud 아키텍처 및 운영 관행 |
| 원칙 2: 자산 보호 및 복원력 |
| 2.1 물리적 위치 및 법적 관할권 | 물리적 위치
현재 Atlassian은 미국, 독일, 아일랜드, 싱가포르, 호주에서 데이터 센터를 유지 관리하고 데이터를 호스팅하고 있습니다. Atlassian은 전 세계 여러 리전에서 콘텐츠를 호스팅하여 모든 고객에게 안전하고 빠르며 신뢰할 수 있는 서비스를 제공합니다.모든 프로덕션 Atlassian Cloud 시스템은 Amazon AWS의 미국 동부 및 미국 서부 리전, AWS 아일랜드 리전, AWS 프랑크푸르트 리전, AWS 시드니 리전 및 AWS 싱가포르 리전에 있습니다.
Atlassian의 플랫폼은 고객이 가입할 때 액세스 지역에 따라서 고객이 데이터가 위치하는 리전을 최적화되므로 보다 안정적인 성능을 보장하고 대기 시간을 줄일 수 있습니다.
현재 Jira Software, Confluence 및 Jira Service Management에 대한 Cloud Standard, Premium 및 Enterprise 플랜의 일부로 데이터 보존을 제공합니다. 특정 제품 데이터를 호주, 유럽 또는 미국에서 호스팅하도록 선택할 수도 있습니다. 데이터 보존 제어에 대해 알아보세요.Cloud 로드맵에서 추가 위치에 대한 데이터 보존, 앱에 대한 데이터 보존 등을 포함한 최신 업데이트 정보를 확인하세요. | 물리적 위치
데이터 보안 유지 | Atlassian Trust Center
Atlassian Cloud 호스팅 인프라 | Atlassian Cloud 아키텍처 및 운영 관행 |
| 데이터 사용
Atlassian의 고객 계약, 개인 정보 보호 정책 및 데이터 처리 부록을 참조하세요. | 데이터 사용
Atlassian 고객 계약 | Atlassian
개인 정보 보호 정책 | Atlassian
데이터 처리 부록 | Atlassian |
| 추가 고려 사항
GDPR 및 기타 데이터 보호법에 대한 Atlassian의 약속을 확인하세요. | 추가 고려 사항
GDPR 약속 | Atlassian | Atlassian |
| 2.2 Data Center 보안 | 이 내용은 Atlassian이 Data Center, 네트워크 보안, 데이터 보안을 포함하여 사용자 데이터를 보호한다는 약속이 명시되어 있는 Atlassian의 데이터 처리 부록에 설명되어 있습니다.
Atlassian은 Data Center에 대한 물리적 위협을 예상하고, 위협의 영향을 방지하거나 제한하는 대응 조치를 시행합니다.
Atlassian 사무실에는 물리적 출입구 모니터링을 포함한 내부 물리적 및 환경 보안 정책이 적용됩니다.
파트너 데이터 센터는 여러 컴플라이언스 인증을 유지합니다. 이 인증은 물리적 보안, 시스템 가용성, 네트워크 및 IP 백본 액세스, 고객 프로비저닝 및 문제 관리를 처리합니다. 데이터 센터에 대한 액세스는 권한이 부여된 직원으로 제한되며 생체 인식 신원 확인을 통해 확인합니다. 물리적 보안 조치에는 온프레미스 보안 요원, 폐쇄 회로 비디오 모니터링, 맨트랩, 추가 침입 보호 조치가 포함됩니다.AWS는 데이터 센터 보호에 대한 여러 인증을 보유하고 있습니다. AWS 물리적 보호 보증 정보는 http://aws.amazon.com/compliance/에서 확인할 수 있습니다. | https://www.atlassian.com/trust/security/securitypractices#physical-security를
참조하세요 |
| 2.3 데이터 암호화 | Atlassian은 기본 공급업체 설정을 수정하는 것을 포함하여 내부 무선 네트워크에서 암호화를 유지합니다. Atlassian의 작업 공간 기술 팀은 WPA2-AES 인증과 PEAP-EAP-MSCHAPv2 암호화를 활용하여 무선 네트워크를 보호합니다. Atlassian은 내부 ID 저장소를 이용하여 802.1x를 통해 무선 네트워크를 인증합니다. Atlassian은 정기적으로 불량 무선 액세스 포인트를 검사하고 발견된 불량 액세스 포인트의 목록을 유지 관리합니다.
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를 참조하세요 | Atlassian의 보안 및 데이터 개인 정보 보호 정책
데이터 암호화 | Atlassian Trust Center 데이터
암호화 | Atlassian Cloud 아키텍처 및 운영 관행 |
| 2.4 데이터 완전 삭제 및 장비 폐기 | 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/를 참조하세요 | 데이터 보존 및 삭제 | Atlassian Trust Center
스토리지 추적 및 제품 간 데이터 이동 | Atlassian 고객 지원팀 |
| 2.5 물리적 복원력 및 가용성 | 사무실의 물리적 보안 컨트롤은 온프레미스 및 클라우드에서 환경 전반에 걸쳐 강력한 물리적 보안을 구현하도록 보장하는 물리적 및 환경적 보안 정책에 따라 이루어집니다. 이 정책은 보안 작업 영역과 같은 영역을 다루며, 설치 위치와 관계없이 IT 장비를 보호하고, 건물 및 사무실에 대한 접근 권한을 해당 개인으로 제한하며, 물리적 출입구를 모니터링합니다. Atlassian의 물리적 보안 관행에는 업무 시간 중의 리셉션 근무, 방문자 등록 요구 사항, 모든 비공개 영역에서 배지 액세스가 포함되며, Atlassian은 사무실 건물 관리자와 협력하여 주 출입구와 화물 취급 영역 모두에서 업무 시간 후 진입 및 출구 지점의 접근 기록 및 비디오 녹화를 수행합니다.Atlassian의 파트너 데이터 센터는 최소한 SOC-2를 준수합니다. 이러한 인증은 물리적 및 환경적 보안 및 보호를 포함한 다양한 보안 컨트롤을 다룹니다. 데이터 센터에 대한 액세스는 권한 있는 직원으로 제한되며 생체 인식 신원 확인 방안을 통해 확인합니다. 물리적 보안 조치에는 온프레미스 보안 요원, 폐쇄 회로 비디오 모니터링, 맨트랩, 추가 침입 보호 조치가 포함됩니다.위 조치 외에도 Atlassian은 자체 Statuspage 제품을 사용하여 고객에게 서비스 가용성 상태를 실시간으로 게시합니다. 따라서 제품에 문제가 있을 경우 고객은 Atlassian이 수행하는 조치를 바로 알 수 있습니다. | 물리적 보안 | Atlassian Trust Center |
| 원칙 3: 고객 간 분리 |
| | 고객은 Atlassian의 제품을 사용할 때 공동의 클라우드 기반 IT 인프라를 공유하지만, Atlassian은 한 고객의 작업으로 인해 다른 고객의 데이터 또는 서비스가 손상되지 않도록 고객을 논리적으로 분리하는 조치를 마련했습니다.Atlassian에서 이것은 달성하는 접근 방식은 애플리케이션에 따라 다릅니다. Jira 및 Confluence Cloud의 경우 논리적 고객 격리를 달성하기 위해 “테넌트 컨텍스트”라는 개념을 사용합니다. 두 개 제품은 애플리케이션 코드에서 구현되며 Atlassian이 구축한 “테넌트 컨텍스트 서비스”(TCS)를 통해 관리합니다. 이 개념은 다음을 보장합니다. - 각 고객의 데이터가 미사용 시 다른 테넌트와 논리적으로 분리됨
- 다른 테넌트가 영향을 받지 않도록 Jira 또는 Confluence가 처리하는 모든 요청에는 “테넌트별” 보기가 있음
넓은 의미에서, TCS는 개별 고객 테넌트의 "컨텍스트"를 저장하여 작동합니다. 각 테넌트의 컨텍스트는 TCS를 통해 중앙에서 저장하는 고유 ID와 연결되며 테넌트와 연결된 다양한 메타데이터(테넌트가 있는 데이터베이스, 테넌트가 보유한 라이선스, 액세스할 수 있는 기능, 다양한 기타 구성 정보 등)를 포함합니다. 고객이 Jira 또는 Confluence Cloud에 액세스하면 TCS가 테넌트 ID를 사용하여 메타데이터를 대조한 후 세션 전체에서 테넌트가 애플리케이션에서 수행하는 모든 작업과 연결합니다.TCS가 제공하는 컨텍스트는 고객 데이터와 상호 작용이 이루어지는 실질적 '렌즈''로서 작용하며, 이 렌즈는 항상 하나의 특정 테넌트에만 국한됩니다. 따라서 하나의 고객 테넌트가 다른 테넌트의 데이터에 액세스하지 않으며, 한 테넌트의 서비스가 자체 작업을 통해 다른 테넌트의 서비스에 영향을 미치지 않습니다.Cloud 아키텍처에 대한 자세한 내용은 Cloud 지원 리소스를 확인하세요. | Atlassian Cloud 아키텍처 및 운영 관행 | Atlassian Trust Center |
| 원칙 4: 거버넌스 프레임워크 |
| | Atlassian은 규제 기관이 위험 평가의 일환으로 서비스에 대한 당사의 내부 컨트롤, 시스템, 데이터 보안 및 개인 정보 보호를 검토해야 한다는 점을 잘 알고 있습니다. Atlassian은 운영 및 내부 컨트롤에 대한 검증을 위해 매년 여러 차례 독립적인 제3자 감사를 수행합니다.
현재 Atlassian의 컴플라이언스 프로그램을 보려면 컴플라이언스 리소스 센터를 방문하여 제품에 대한 다운로드 가능한 확인 및 인증을 확인하세요.
Atlassian에는 COSO 위험 모델 및 ISO 31000에 부합하는 엔터프라이즈 위험 관리(ERM) 프로그램이 있습니다. ERM 프로그램에 따라 Atlassian 전체에 위험 관리 프레임워크와 방법론을 시행하고, 위험 프로필을 기반으로 연간 위험 평가, 제품 환경에 대한 주기적 특정 위험 평가, 그리고 필요에 따라 기능적 위험 평가를 수행합니다.
특히 Atlassian의 위험 관리 프레임워크는 위험 평가 활동을 완료하기 위한 표준, 프로세스, 역할 및 책임, 허용되는 위험의 범위 및 지침을 제공합니다. Atlassian의 위험 관리 프로세스와 관행은 유효하고 일관적이며 비교 가능한 결과를 산출하는 반복 가능한 위험 평가를 완료하도록 안내합니다. Atlassian이 수행하는 위험 평가에는 모든 위험 범주에 대한 가능성 및 영향, 그리고 내부적으로 설정된 위험 성향에 따른 모든 위험에 대한 처리 방식이 포함되어 있습니다. 위험 및 컴플라이언스 팀은 ERM 프로그램의 모든 단계에서 관련 이해 관계자와 소통하고 적절한 SME와 상의합니다. | Atlassian의 보안 및 데이터 개인 정보 보호 정책
컴플라이언스 및 위험 관리 | Atlassian Trust Center
Atlassian Trust Management System(ATMS) | Atlassian Trust Center
데이터 처리 부록 | Atlassian Trust Center |
| 원칙 5: 운영 보안 |
| 5.1 취약성 관리 | Atlassian은 제품, 서비스, 인프라에서 취약성의 심각도와 빈도를 줄이고 식별한 취약성을 최대한 빠르게 해결하기 위해 끊임없이 노력하고 있습니다. 이를 위해 Atlassian은 애플리케이션 및 인프라 전반에서 자동 프로세스와 수동 프로세스를 모두 활용하여 취약성을 찾아내고 이를 추적 및 해결하기 위해 다각적이고 지속적으로 발전하는 취약성 관리 접근 방식을 시행하고 있습니다.
또한 모든 제품 및 서비스 제공에 대한 광범위한 버그 수정 프로세스를 보유하고 있습니다(이슈를 캡처하고 요청 해결을 관리하는 데 도움이 되는 자체 제품 Jira를 활용). Atlassian이 준수하는 수많은 보안 버그 수정 정책, 자문 서비스 및 SLO는 이러한 프로세스를 뒷받침합니다. 버그 신고는 지원 채널, 버그 바운티 프로그램, security@atlassian.com을 통해 접수합니다. 보안 버그 수정 SLO(https://www.atlassian.com/trust/security/bug-fix-policy)에 대한 자세한 내용은 Trust Center(https://www.atlassian.com/trust)에서 확인할 수 있습니다 .
Atlassian 보안 팀은 내부 및 외부 인프라의 취약성을 탐지하기 위해 여러 방법을 사용합니다. 취약성을 추적하고 수정하기 위한 Jira 티켓을 만들고, 취약성의 출처와 심각도를 기준으로 SLO에 따라 기한을 할당합니다. 확인된 취약성 티켓을 시스템 소유자에게 발행하는 절차가 진행 중이며, 보안 관리 팀은 보고된 취약성을 검토하여 조치를 취할 수 있습니다.
자세한 내용은 Atlassian의 취약성 관리 접근 방식에 대한 전용 문서에서 확인할 수 있습니다.
Atlassian의 보안 테스트 접근 방식에 관한 자세한 내용은 Trust Center의 외부 보안 테스트 접근 방식 | Atlassian에서도 확인할 수 있습니다 | 취약성 관리 | Atlassian Trust Center
보안 버그 수정 정책 | Atlassian Trust Center
외부 보안 테스트 접근 방식 | Atlassian Trust Center
취약성 관리 접근 방식 | Atlassian Trust Center |
| 5.2 보호 모니터링 | Atlassian은 복잡한 위협 환경이 증가하고 있는 상황에서 인시던트 관리 접근 방식을 기반으로 프로그램을 구축해야 하는 필요성을 인식하여 “보안 감지 프로그램”을 도입했습니다. 이 프로그램은 Atlassian의 보안 인시던트 및 이벤트 관리 플랫폼에서 일정에 따라 사전 예방적으로 실행하여 Atlassian 및 고객을 표적으로 하는 악의적인 활동을 탐지하는 검색입니다.
Atlassian의 탐지 및 대응 팀은 정기적으로 새로운 탐지를 만들고, 기존 탐지를 조정 및 개선하며, 탐지 대응을 자동화하는 데 집중하고 있습니다. 보안 인텔리전스 팀은 탐지 적용 범위를 최대한 효과적이고 포괄적으로 유지할 수 있도록 제품, 공격 유형, 로그 소스를 포함한 여러 차원에서 이러한 작업을 수행합니다.
이 프로그램의 목적은 현재 직면하고 있는 문제에 대응할 수 있는 준비를 갖출 뿐만 아니라 미래의 위협 상황을 충분히 예상하고 대비할 수 있게 하는 것입니다. 탐지 및 대응 팀은 현재 실행 중인 탐지 프로그램에 대해 높은 수준의 일관성 및 품질을 보장하기 위해 만드는 탐지 프로그램을 표준화할 수 있는 도구도 만들었으며 업계에서 최초라고 생각합니다.
사무실과 Cloud 호스팅 환경에 IDS를 배포했습니다. Atlassian Cloud 플랫폼의 경우 보안 분석 플랫폼에 로그 전달 기능이 통합되었습니다. 각 시스템의 키 시스템 로그는 읽기 전용으로 로그를 확인할 수 있는 중앙 집중식 로그 플랫폼으로 전달됩니다. Atlassian 보안 팀은 보안 분석 플랫폼(Splunk)에 대한 알림을 만들고 침해 지표를 모니터링합니다. SRE 팀은 이 플랫폼을 사용하여 가용성 또는 성능 문제를 모니터링합니다. 로그는 핫 백업에서 30일간, 콜드 백업에서 365일간 보관됩니다.
감지 프로그램에 대한 자세한 내용은 https://www.atlassian.com/trust/security/detections-program을 참조하세요 | Atlassian 감지 프로그램 | Atlassian Trust Center
로그 활용 | Atlassian Trust Center
데이터 처리 부록 | Atlassian Trust Center |
| 5.3 인시던트 관리 | Atlassian은 보안 인시던트 처리에 대한 종합적인 접근 방식을 제공합니다. Atlassian은 보안 인시던트를 고객 데이터, Atlassian 데이터 또는 Atlassian 서비스의 기밀성, 무결성 또는 가용성에 부정적인 영향을 미치는 사례로 간주합니다.따라서 Atlassian은 다양한 인시던트 유형에 대한 문서화된 플레이북을 포함하는 내부 프레임워크를 명확하게 정의했습니다. 이 프레임워크는 인시던트 대응의 모든 단계에서 프로세스 일관성, 반복성, 효율성을 보장하기 위해 취해야 하는 모든 조치를 다룹니다. 여기에는 인시던트 감지 및 분석의 적용 범위, 인시던트 분류, 봉쇄, 제거 및 복구가 포함됩니다. 이 일관성은 인시던트 대응 프로세스의 일부분으로 Confluence, Jira 및 Bitbucket을 포함한 자체 제품을 사용하여 지원합니다. - Confluence는 중앙 집중식 위치에서 대응 프로세스를 만들고, 문서화하고, 업데이트하는 데 사용합니다.
- Jira는 잠재적이거나 실제적인 보안 인시던트에 대한 대응 프로세스의 진행 상황을 처음부터 끝까지 추적하는 티켓을 만드는 데 사용합니다
- Bitbucket은 특정 인시던트에서 발생하는 특정 예외적인 문제에 대응하기 위한 코드 기반 솔루션을 배포하는 경우에 사용합니다.
제품 및 인프라에 대한 종합적인 중앙 집중식 로깅과 모니터링이 마련되어 있어 잠재적 인시던트를 빠르게 감지하고 효과적인 대응을 조정하는 데 많은 경험을 보유한 숙련된 대기 중 인시던트 관리자의 지원을 받을 수 있습니다. Atlassian은 또한 다양한 외부 전문가의 지원을 받아 최대한 효과적으로 조사하고 대응할 수 있습니다.
Atlassian은 고객의 데이터가 확인된 인시던트와 관련된 경우 고객에게 알리기 위해 알림 프로세스를 마련했으며, 인시던트에서 교훈을 얻고 관행을 개선하여 향후 악의적인 행위자의 행위를 더 어렵게 만들 수 있도록 강력한 사후 인시던트 검토 프로세스를 보유하고 있습니다. 자세한 내용은 Atlassian Trust Center의 보안 인시던트 관리 접근 방식에 대한 문서를 참조하세요. | 인시던트 관리 | Atlassian Trust Center
데이터 처리 부록 | Atlassian Trust Center |
| 5.4 구성 및 변경 관리 | Atlassian의 변경 관리 프로세스는 기존의 변경 관리 프로세스와 약간 다릅니다. 기존의 변경 관리 프로세스는 피라미드 스타일의 변경 제어 계층에 의존합니다. 다시 말해, 누군가가 변경을 원하는 경우 위원회에서 변경을 제시하고 위원회에서 최종적으로 승인 또는 거부합니다.
Atlassian은 PRGB(“동료 검토, 그린 빌드”)라는 오픈 소스 스타일의 접근 방식을 채택했습니다. 기존의 변경 관리 프로세스와 대조적으로 PRGB 접근 방식은 코드 변경 또는 인프라 변경 등 각 변경을 한 명 이상의 동료가 검토하여 변경으로 인해 발생할 수 있는 문제를 식별해야 합니다. Atlassian은 엔지니어가 문제를 식별한 후 변경을 적용하기 전에 문제를 제기할 수 있다는신뢰를 바탕으로 변경의 중요도 또는 변경이 영향을 미치는 시스템의 중요도에 따라 검토자의 수를 늘립니다. 이 프로세스는 환경에서 변경을 관리할 수 있는 동적이고 조정 가능한 방법을 제공하는 데 효과적입니다. 이 제어의 그린 빌드 부분은 새로운 변경 사항이 포함된 CI/CD에서의 성공적인 빌드 또는 클린 빌드를 나타냅니다. 변경 시 통합, 기능, 단위 또는 보안 테스트를 성공적으로 통과하지 못하는 구성 요소가 있는 경우 빌드가 거부되고, 문제를 해결하기 위해 원래 변경 요청으로 돌아갑니다.Atlassian에서는 기존의 '품질 보증'이 아닌 '품질 지원'을 사용하는 접근 방식을 지향합니다. 자세한 내용은 https://www.atlassian.com/inside-atlassian/quality-assurance-vs-quality-assistance를 확인하세요 | 환경 변화 관리 | Atlassian Trust Center
품질 보증에서 품질 지원으로 전환하는 방법 |
| 원칙 6: 인적 보안 |
| | 회사 가치
Atlassian의 회사 가치에 대한 정보는 https://www.atlassian.com/company/values에서 확인할 수 있습니다
| 회사 가치
회사 가치 | Atlassian
|
| 직원 신원 조사
전 세계의 Atlassian 신규 직원은 신원 조사를 완료해야 합니다. 인수를 통해 새로 고용된 직원은 인수일 이후에 신원 조사를 실시합니다. 모든 신규 직원 및 독립 계약자에 대해 범죄 조사를 실시하며 역할이나 직급에 따라 필요한 경우 학력 확인, 고용 확인 또는 신용 확인을 추가로 실시합니다. Atlassian은 고위 경영진 및 회계 관련 직원에 대해 완전한 신원 조사를 실시합니다. | 직원 신원 조회
신원 조회 | Atlassian Trust Center |
| 모든 Atlassian 직원 대상의 보안 교육
Atlassian은 신규 직원을 위한 온보딩 교육('1일 차') 중 하나로, 그리고 모든 직원에게 지속적으로 정보 보안 교육을 제공합니다.
일반 정보 보안 교육 외에도 개발자에게 보안 코딩에 대한 더 구체적인 교육을 제공하며, 이러한 교육은 포함된 보안 엔지니어 프로그램을 통해 지원됩니다.
맬웨어, 피싱 및 기타 보안 문제와 관련된 주제별 교육도 지속적으로 제공하고 있습니다. 보안 인식 | Atlassian Trust Center | 모든 Atlassian 직원 대상의 보안 교육
보안 인식 | Atlassian Trust Center |
| 원칙 7: 안전 개발 | Atlassian은 개발 수명 주기의 모든 단계에서 안전한 개발 관행을 수행합니다. 자세한 내용은 https://www.atlassian.com/trust/security/security-in-development를 참조하세요.
설계 단계에서는 위협 모델링, 설계 검토 및 정기적으로 업데이트되는 보안 표준 라이브러리를 포함한 관행을 따르며, 이를 통해 적절한 보안 요구 사항을 고려할 수 있습니다.
개발 단계에서는 첫 보안 검토 단계로 필수 동료 검토 프로세스를 활용합니다. 이 프로세스는 위험 평가 프로세스에 명시된 내부 팀 및 타사 전문가가 모두 수행하는 수동 보안 테스트 및 자동 정적 분석 검사(SAST)로 뒷받침됩니다. 개발 단계에서는 보안 팀에서 관리하는 애플리케이션 보안 교육 프로그램과 보안 기술 자료의 지원도 받습니다.
공식 운영 준비성 및 변경 제어 프로세스를 통해 승인된 변경 사항만 프로덕션에 배포됩니다. 배포 후에는 정기적인 자동 취약성 검사와 업계 최고의 버그 바운티 프로그램(Atlassian의 버그 바운티 프로그램 | Bugcrowd )을 활용하여 애플리케이션에 대한 지속적인 보증을 제공합니다.
그리고 Atlassian의 SOC 2 보고서도 검토할 수 있습니다. 보고서는 보안, 가용성, 처리 무결성, 기밀성, 개인 정보 보호와 관련된 조직 시스템의 평가에 중점을 둡니다. | 데이터 처리 부록 | Atlassian Trust Center |
| 원칙 8: 공급망 보안 | Atlassian은 타사 공급업체(계약업체 및 클라우드 서비스 공급자 포함)를 참여시킬 경우 그러한 참여가 어떤 식으로든 고객 또는 고객의 데이터를 위태롭게 하지 않도록 주의를 기울입니다. 이런 목적으로 법무 및 조달 팀은 제안된 타사 공급업체 참여에 대해 검토 프로세스를 수행합니다. 높은 위험 또는 중요한 위험으로 간주되는 참여에 대해서는 보안, 위험 및 컴플라이언스 팀이 추가 검토를 진행해야 합니다. 참여의 위험 수준에 따라 계약 갱신 시 또는 매년 후속 검토를 통한 지속적인 실사도 이루어집니다.또한 Atlassian은 공급업체에 참여의 일환으로 최소 공급업체 보안 요구 사항을 준수할 것을 요구합니다. 이러한 요구 사항은 공급업체 계약서에 포함된 내용을 통해 적용되며, 참여의 위험 수준에 따라 다르고, 다음을 포함합니다. - Atlassian의 SSO(Single Sign-On) 플랫폼과 SAML 통합
- 사용이 중단되지 않은 알고리즘을 사용하여 전송 중이거나 보관 중인 데이터 암호화
- Atlassian에 잠재적인 보안 인시던트에 관한 정보를 제공할 수 있는 충분한 로깅 메커니즘 확립
| 공급업체 위험 관리 | Atlassian Trust Center
Atlassian SOC 2 | 29페이지(공급업체 관리) |
| 원칙 9: 안전한 사용자 관리 |
| 9.1 관리 인터페이스와 지원 채널에 대한 사용자 인증 | Atlassian에서는 이 부분이 고객과 Atlassian의 공동 책임이라고 생각합니다.
인증된 사용자
Atlassian은 모든 고객 데이터를 동일하게 민감한 데이터로 처리하며 이 데이터를 관리하는 엄격한 컨트롤을 구현했습니다. 또한 온보딩 프로세스 중에 내부 직원과 계약업체에 고객 데이터 처리의 중요성과 모범 사례를 다루는 인식 교육을 제공합니다.Atlassian 내에서 권한 있는 Atlassian 직원만 애플리케이션에 저장된 고객 데이터에 액세스할 수 있습니다. 인증은 개별 암호로 보호된 공개 키를 통해 수행되며 서버는 Atlassian과 내부 데이터 센터에서 수신되는 SSH 연결만 허용합니다. 요청 및 검토되지 않는 한 모든 액세스는 권한 있는 그룹으로 제한되며 추가 인증에는 2FA가 필요합니다.확립된 엄격한 인증 및 권한 부여 제어를 통해 글로벌 지원 팀은 유지 관리 및 지원 프로세스를 원활하게 수행할 수 있습니다. 호스팅된 애플리케이션과 데이터에는 애플리케이션 상태를 모니터링하고 시스템 또는 애플리케이션을 유지 관리하기 위해 또는 지원 시스템을 통해 고객이 요청할 경우 액세스할 수 있습니다. 고객에게는 동의 제어 확인 기능을 통해 고객 데이터에 액세스할 수 있는 지원 엔지니어와 관련하여 명시적으로 동의할 수 있는 옵션이 제공됩니다.고객 데이터에 대한 무단 또는 부적절한 액세스는 보안 인시던트로 취급되며, 인시던트 관리 프로세스를 통해 관리합니다. 이 프로세스는 정책 위반이 관찰되는 경우 영향을 받는 고객에게 알리는 지침을 포함합니다. | 고객 데이터에 대한 액세스 제어 | Atlassian Trust Center
데이터 처리 부록 | Atlassian Trust Center |
| 9.2 관리 인터페이스 내의 분리 및 액세스 제어 | 이 AWS 아키텍처를 통해 Atlassian은 솔루션 전반에 사용하는 다양한 플랫폼 및 제품 서비스를 호스팅합니다. 여기에는 미디어, ID, 상거래, 편집기와 같은 환경, Jira 이슈 서비스 및 Confluence 분석과 같은 제품별 기능 등 여러 Atlassian 제품에서 공유 및 사용하는 플랫폼 기능이 포함됩니다.
Atlassian 개발자는 Micros라고 하는 내부적으로 개발된 PaaS(Platform-as-a-Service)를 통해 이 서비스를 프로비저닝합니다. PaaS는 공유 서비스, 인프라, 데이터 저장소 및 보안 및 컴플라이언스 컨트롤 요구 사항을 포함한 관리 기능의 배포를 자동으로 오케스트레이션합니다(위의 그림 1 참조). 일반적으로 Atlassian 제품은 Micros를 사용하여 AWS에 배포한 여러 "컨테이너화된" 서비스로 구성됩니다. Atlassian 제품은 요청 라우팅에서 바이너리 개체 저장소, 인증/권한 부여, 트랜잭션 사용자 생성 콘텐츠(UGC)와 엔터티 관계 저장소, 데이터 레이크, 공통 로깅, 요청 추적, 관찰 가능성 및 분석 서비스에 이르는 핵심 플랫폼 기능(아래의 그림 2 참조)을 사용합니다.Atlassian은 클라우드 인프라 외에도 제품을 지원하는 공유 플랫폼을 사용하여 다중 테넌트 마이크로 서비스 아키텍처를 구축하고 운영합니다. 다중 테넌트 아키텍처에서 단일 서비스가 여러 고객에게 서비스를 제공하며 여기에는 클라우드 제품을 실행하는 데 필요한 데이터베이스 및 컴퓨팅 인스턴스가 포함됩니다. 각 샤드(본질적으로 컨테이너 - 아래 그림 3 참조)에는 여러 테넌트에 대한 데이터가 포함되어 있지만 각 테넌트의 데이터는 격리되어 다른 테넌트가 액세스할 수 없습니다. Atlassian에서는 단일 테넌트 아키텍처를 제공하지 않는다는 점이 중요합니다.자세히 알아보려면 https://www.atlassian.com/trust/reliability/cloud-architecture-and-operational-practices#cloud-infrastructure를 방문하세요 | 멀티 테넌트 아키텍처 | Atlassian Cloud 아키텍처 및 운영 관행
데이터 처리 부록 | Atlassian Trust Center |
| 원칙 10: ID 및 인증 |
| | 인증 및 액세스 관리에 대한 자세한 내용은 9.1과 9.2를 참조하세요. | 해당 없음 |
| 원칙 11: 외부 인터페이스 보호 |
| | Atlassian Trust가 Cloud 고객을 보호하는 방법에 대한 자세한 내용은 원칙 5를 참조하세요. | 해당 없음 |
| 원칙 12: 안전한 서비스 관리 |
| | Atlassian의 데이터 처리 부록에서 Atlassian은 액세스 제어 권한 관리를 포함하여 고객 데이터를 보호하기로 약속합니다.
인증 및 액세스 관리에 대한 자세한 내용은 9.1과 9.2를 참조하세요. | 해당 없음 |
| 원칙 13: 사용자를 위한 감사 정보 |
| | 고객 애플리케이션에 대한 모든 액세스가 로그됩니다. 모든 사용자 인터페이스 상호작용은 애플리케이션 감사 로그에 기록됩니다.
Atlassian은 Atlassian 계정 ID 저장소와 기타 정보 보안 관리 시스템에 대한 권한 있는 액세스를 제한하고 로그하며 모니터링합니다.
로그는 논리적으로 별도의 시스템에 저장되며 로그에 대한 쓰기 액세스는 보안 팀원만 가능하도록 제한됩니다. 로그에서 특정 작업이나 이벤트가 식별되면 보안 팀이나 서비스 데스크에 알림이 전송됩니다. 중앙 집중식 로깅 서비스(Atlassian Cloud Platform, JIRA, Confluence, Bamboo 포함)는 자동 분석을 위한 보안 분석 인프라에 통합되며, 잠재적 이슈를 식별하기 위한 알림을 만듭니다.
Bitbucket의 경우 감사 로그는 인시던트 후 조사에 사용됩니다. Puppet 관리형 서비스 구성과 선언형 구성 형식이 매니페스트에 의해 관리되는 모든 시스템 구성이 실행될 때마다 올바르게 구성되도록 보장합니다. 해당 서버에서 Puppet이 실행되지 못하면 모니터링 알림이 발생합니다. 내부 및 외부 취약성 검사기에는 예상치 못한 포트가 열려 있는 상황이나 기타 구성 변경(예: 수신 서버의 TLS 프로필)이 발생하는 경우 전송하는 알림이 포함되어 있습니다.
자세한 내용은 Atlassian Access | Jira, Confluence 등을 위한 보안 및 SSO를 참조하세요.
Atlassian 내부에서 로그는 논리적으로 분리된 시스템에 저장되며 로그에 대한 쓰기 액세스는 보안 팀과 관찰 가능성 팀으로 제한됩니다. 중앙 집중식 로깅 서비스가 자동 분석을 위한 보안 분석 인프라에 통합되며, 잠재적 이슈를 식별하기 위한 알림을 만듭니다.
Atlassian Cloud 고객은 Atlassian Access 기능 중 하나인 조직 변경 사항에 대한 감사 로그를 이용할 수 있습니다. 감사 로그를 사용하면 사용자, 그룹, 권한 등에 대한 관리자 작업을 확인할 수 있습니다. 자세한 정보는 https://support.atlassian.com/security-and-access-policies/docs/track-organization-activities-from-the-audit-log/에서 확인하세요
Atlassian Cloud 제품에는 제품별 변경 사항에 대한 자체 감사 로깅도 있습니다. | 해당 없음 |
| 원칙 14: 서비스의 안전한 사용 |
| | Atlassian에서는 이 부분이 고객과 Atlassian의 공동 책임이라고 생각합니다.
이 문서뿐만 아니라 Atlassian의 취약성 관리 접근 방식과 보안에 대해 자세히 알아보기 위해 더 일반적으로 참조할 수 있는 다양한 기타 리소스가 있습니다. | 해당 없음 |