Atlassian Cloud 아키텍처 및 운영 사례

Atlassian Cloud 호스팅 아키텍처

Atlassian은 클라우드 서비스 공급자로 AWS(Amazon Web Services)를 사용하며 전 세계 여러 리전에 있는 AWS의 고가용성 Data Center 시설을 활용합니다. 각 AWS 리전은 독립된 지리적 위치이며, 여기에는 가용성 영역(AZ)이라는 격리되고 물리적으로 분리된 여러 데이터 센터 그룹이 있습니다.

Atlassian은 AWS의 컴퓨팅, 스토리지, 네트워크 및 데이터 서비스를 활용하여 제품 및 플랫폼 구성 요소를 구축하므로, 가용성 영역 및 리전과 같은 AWS에서 제공하는 이중화 기능을 활용할 수 있습니다.

가용성 영역

각 가용성 영역은 다른 영역의 장애와 분리되고 동일한 리전의 다른 AZ에 낮은 비용으로 대기 시간이 짧은 네트워크 연결을 제공하도록 설계되었습니다. 이 다중 영역 고가용성은 지리적 및 환경적 위험에 대한 1차 방어선이며, 이것은 다중 AZ 배포에서 실행되는 서비스는 AZ 장애를 견딜 수 있어야 한다는 것을 의미합니다.

Jira와 Confluence는 Amazon RDS(Amazon 관계형 데이터베이스 서비스)의 다중 AZ 배포 모드를 활용합니다. 다중 AZ 배포에서 Amazon RDS는 동일한 리전의 다른 AZ에서 동기식 예비 복제본을 프로비저닝 및 유지 관리하여 이중화와 장애 조치 기능을 제공합니다. AZ 장애 조치는 자동화되어 있으며 일반적으로 60~120초가 소요되므로 관리자의 개입 없이 데이터베이스 운영을 최대한 빨리 재개할 수 있습니다. Opsgenie, Statuspage, Trello 및 Jira Align은 복제 타이밍과 장애 조치 타이밍이 약간 다른 유사한 배포 전략을 사용합니다.

데이터 위치

Jira 및 Confluence 데이터는 등록 시 대부분의 사용자가 위치한 곳과 가장 가까운 리전에 위치합니다. 그러나 일부 사용자는 데이터를 특정 지역에 보관해야 할 수 있으므로 Atlassian은 데이터 보존 서비스를 제공합니다. 현재 호주뿐만 아니라 미국 및 EU 리전에서도 데이터 보존을 제공하고 있으며 더 많은 리전을 추가할 계획입니다. 자세한 내용과 업데이트 등록은 데이터 보존 페이지를 참조하세요.

Data for Bitbucket is located in two different availability zones in the US-East region.

데이터 백업

Atlassian은 종합적인 백업 프로그램을 운영하고 있습니다. 여기에는 시스템 복구 요구 사항에 따라 백업 조치가 설계된 내부 시스템이 포함됩니다. Atlassian Cloud 제품과 관련해서, 특히 고객 및 애플리케이션 데이터에 대한 광범위한 백업 조치도 마련되어 있습니다. Atlassian은 Amazon RDS(관계형 데이터베이스 서비스)의 스냅샷 기능을 사용하여 각 RDS 인스턴스를 매일 자동으로 백업합니다.

Amazon RDS 스냅샷은 특정 시점으로 복구를 포함하여 30일 동안 보관되며 AES-256 암호화를 사용하여 암호화합니다. 백업 데이터는 오프사이트에 저장되지 않지만 특정 AWS 리전의 여러 데이터 센터에 복제됩니다. Atlassian은 분기별 백업 테스트도 수행합니다.

For Bitbucket, storage snapshots are retained for 7 days with support for point-in-time recovery.

Atlassian은 스크립트를 사용하여 재정의된 필드 또는 삭제된 이슈, 프로젝트 또는 사이트와 같이 고객이 시작한 파괴적인 변경 사항을 되돌리는 데 이 백업을 사용하지 않습니다. 데이터 손실을 방지하려면 정기적으로 백업하는 것이 좋습니다. 제품의 지원 문서에서 백업을 만드는 방법에 대해 자세히 알아보세요.

데이터 센터 보안

AWS는 데이터 센터 보호에 대한 여러 인증을 보유하고 있습니다. 이러한 인증은 물리적 및 환경적 보안, 시스템 가용성, 네트워크 및 IP 백본 액세스, 고객 프로비저닝 및 문제 관리를 다룹니다. 데이터 센터에 대한 액세스는 권한이 부여된 직원으로 제한되며 생체 인식 신원 확인을 통해 확인합니다. 물리적 보안 조치에는 온프레미스 보안 요원, 폐쇄 회로 비디오 모니터링, 맨트랩, 추가 침입 보호 조치가 포함됩니다.

분산된 서비스 아키텍처

이 AWS 아키텍처를 통해 Atlassian은 솔루션 전반에 사용하는 다양한 플랫폼 및 제품 서비스를 호스팅합니다. 여기에는 미디어, ID, 상거래, 편집기와 같은 환경, Jira 이슈 서비스 및 Confluence 분석과 같은 제품별 기능 등 여러 Atlassian 제품에서 공유 및 사용하는 플랫폼 기능을 포함합니다.

다중 테넌트 아키텍처

Atlassian은 클라우드 인프라 외에도 제품을 지원하는 공유 플랫폼을 사용하여 다중 테넌트 마이크로 서비스 아키텍처를 구축하고 운영합니다. 다중 테넌트 아키텍처에서 단일 서비스가 여러 고객에게 서비스를 제공하며 여기에는 클라우드 제품을 실행하는 데 필요한 데이터베이스 및 컴퓨팅 인스턴스가 포함됩니다. 각 샤드(본질적으로 컨테이너 - 아래 그림 3 참조)에는 여러 테넌트에 대한 데이터가 포함되어 있지만 각 테넌트의 데이터는 격리되어 다른 테넌트가 액세스할 수 없습니다. Atlassian에서는 단일 테넌트 아키텍처를 제공하지 않는다는 점이 중요합니다.

테넌트 프로비저닝 및 수명 주기

신규 고객을 프로비저닝하면 일련의 이벤트가 분산된 서비스의 오케스트레이션 및 데이터 스토어의 프로비저닝을 트리거합니다. 이 이벤트는 다음과 같이 일반적으로 수명 주기의 7단계 중 하나에 매핑할 수 있습니다.

1. 상거래 시스템은 고객에 대한 최신 메타데이터 및 액세스 제어 정보로 즉시 업데이트되며, 프로비저닝 오케스트레이션 시스템은 일련의 테넌트 및 제품 이벤트를 통해 “프로비저닝한 리소스의 상태”를 라이선스 상태에 정렬합니다.

테넌트 이벤트

이 이벤트는 테넌트에 전체적으로 영향을 미치며 다음 중 하나가 될 수 있습니다.

• 만들기: 테넌트를 만들어서 새로운 사이트에 사용합니다
• 소멸: 전체 테넌트를 삭제합니다

제품 이벤트

• 활성화: 라이선스가 부여된 제품 또는 타사 앱을 활성화한 이후
• 비활성화: 특정 제품 또는 앱을 비활성화한 이후
• 일시 중단: 지정된 기존 제품을 일시 중단하여 소유한 사이트에 대한 액세스를 사용 중지한 이후
• 일시 중단 해제: 지정된 기존 제품의 일시 중단을 취소하여 소유한 사이트에 대한 액세스를 사용으로 설정한 이후
• 라이선스 업데이트: 지정된 제품의 라이선스 시트 수 및 상태(활성/비활성)에 대한 정보를 포함

2. 고객 사이트를 만들고 고객을 위해 올바른 제품 그룹을 활성화합니다. 사이트의 개념은 특정 고객에게 라이선스가 부여된 여러 제품의 컨테이너입니다. (예: ＜사이트 이름＞.atlassian.net의 Confluence 및 Jira Software).

테넌트 분리

고객은 Atlassian의 Cloud 제품을 사용할 때 공동의 클라우드 기반 인프라를 공유하지만, Atlassian에는 한 고객의 작업으로 인해 다른 고객의 데이터 또는 서비스가 손상되지 않도록 고객을 논리적으로 분리하는 조치가 있습니다.

Atlassian에서 이것은 달성하는 접근 방식은 애플리케이션에 따라 다릅니다. Jira 및 Confluence Cloud의 경우 논리적 고객 분리를 달성하기 위해 “테넌트 컨텍스트”라는 개념을 사용합니다. 이것을 애플리케이션 코드에서 구현하며 Atlassian이 구축한 “테넌트 컨텍스트 서비스”(TCS)를 통해 관리합니다. 이 개념은 다음을 보장합니다.

• 각 고객의 데이터가 미사용 시 다른 테넌트와 논리적으로 분리됨
• 다른 테넌트가 영향을 받지 않도록 Jira 또는 Confluence가 처리하는 모든 요청은 테넌트에 지정된 보기를 갖게 됨

넓은 의미에서, TCS는 개별 고객 테넌트의 컨텍스트를 저장하여 작동합니다. 각 테넌트의 컨텍스트는 TCS를 통해 중앙에서 저장하는 고유 ID와 연결되며 테넌트와 연결된 다양한 메타데이터(테넌트가 있는 데이터베이스, 테넌트가 보유한 라이선스, 액세스할 수 있는 기능, 다양한 기타 구성 정보 등)를 포함합니다. 고객이 Jira 또는 Confluence Cloud에 액세스하면 TCS가 테넌트 ID를 사용하여 메타데이터를 대조한 후 세션 전체에서 테넌트가 애플리케이션에서 수행하는 모든 작업과 연결합니다.

Atlassian Edge

데이터는 Atlassian에서 Edge라고 부르는 것, 즉 소프트웨어 주변에 구축하는 가상의 벽을 통해서도 보호합니다. 요청이 들어오면 가장 가까운 Edge로 보내며 여러 유효성 검사 절차를 거쳐 요청을 허용 또는 거부합니다.

• 사용자와 가장 가까운 Atlassian Edge에 도착합니다. Edge에서 ID 시스템을 통해 사용자의 세션과 ID를 확인합니다.
• Edge에서 TCS 정보의 데이터를 기반으로 제품 데이터의 위치를 판단합니다.
• Edge에서 요청을 대상 리전으로 전달하며, 요청은 컴퓨팅 노드에 도달합니다.
• 노드는 테넌트 구성 시스템을 사용하여 라이선스 및 데이터베이스 위치와 같은 정보를 결정하고 다양한 다른 데이터 스토리지 및 서비스(예: 이미지 및 첨부 파일을 호스팅하는 미디어 플랫폼)를 호출하여 요청을 처리하는 데 필요한 정보를 검색합니다.
• 다른 서비스에 대한 이전 호출에서 조합한 정보를 사용하여 원래 사용자가 요청합니다.

서비스 인증 및 권한 부여

Atlassian 플랫폼은 데이터에 액세스에 대해 최소 권한 모델을 사용합니다. 즉, 모든 데이터는 저장, 처리 또는 검색을 담당하는 서비스로만 제한됩니다. 예를 들어 Cloud 제품 전반에 걸쳐 일관적인 파일 업로드 및 다운로드 환경을 제공할 수 있는 미디어 서비스에는 Atlassian 외의 다른 서비스가 액세스할 수 없는 전용 스토리지가 프로비저닝되어 있습니다. 미디어 콘텐츠에 액세스해야 하는 모든 서비스는 미디어 서비스 API와 상호 작용해야 합니다. 결과적으로 서비스 계층에서의 강력한 인증 및 권한 부여를 통해 업무 분리가 강화되고 데이터에 대한 액세스 권한이 최소화됩니다.

Atlassian은 JSON 웹 토큰(JWT)을 사용하여 애플리케이션 외부의 서명 권한을 보장하므로 ID 시스템과 테넌트 컨텍스트가 정보의 소스입니다. 토큰은 권한이 부여된 이외의 용도로 사용할 수 없습니다. 사용자 또는 팀의 누군가가 마이크로서비스 또는 사드를 호출하면 토큰이 ID 시스템으로 전달되고 유효성을 검사합니다. 이 프로세스는 적절한 데이터를 공유하기 전에 토큰이 최신 상태이고 서명되었는지 확인합니다. 이러한 마이크로서비스에 액세스하는 데 필요한 권한 부여 및 인증과 결합하면 서비스가 손상된 경우 범위가 제한됩니다.

그러나 때로는 ID 시스템이 손상될 수도 있습니다. 위험을 완화하기 위해 Atlassian은 두 가지 방법을 사용합니다. 첫째, TCS 및 ID 프록시가 고도로 복제됩니다. Atlassian은 거의 모든 마이크로서비스에 대한 TCS 사이드카를 가지고 있으며 ID 기관에 분기하는 프록시 사이드카를 사용하므로 수천 개의 서비스가 항상 실행되고 있습니다. 하나 이상에 비정상적인 동작이 있는 경우 이것을 신속하게 파악하여 문제를 수정할 수 있습니다.

또한 누군가 Atlassian 제품 또는 플랫폼에서 취약점을 발견할 때까지 기다리지 않습니다. Atlassian은 사용자에게 미치는 영향을 최소화하도록 이러한 시나리오를 적극적으로 식별하고 있으며, 보안 위협을 식별, 감지 및 대응하기 위한 여러 보안 프로그램을 운영하고 있습니다.

테넌트 컨텍스트 서비스

Atlassian은 마이크로서비스에 대한 요청에 액세스를 요청하는 고객 또는 테넌트에 대한 메타데이터가 포함되어 있는지 확인합니다. 이것을 테넌트 컨텍스트 서비스라고 합니다. 프로비저닝 시스템에서 직접 채워집니다. 요청을 시작하면 컨텍스트를 읽고 실행 중인 서비스 코드 안에 내부화되어 사용자에게 권한을 부여하는 데 사용합니다. Jira 및 Confluence의 모든 서비스 액세스, 그리고 데이터 액세스에는 이 테넌트 컨텍스트가 필요하며 그렇지 않으면 요청이 거부됩니다.

서비스 인증 및 권한 부여는 Atlassian 서비스 인증 프로토콜(ASAP)을 통해 적용됩니다. 명시적 허용 목록은 통신할 수 있는 서비스를 결정하고, 권한 부여 세부 정보는 어떤 명령 및 경로를 사용할 수 있는지 지정합니다. 이 조치는 손상된 서비스의 잠재적인 수평 이동을 제한합니다.

서비스 인증 및 권한 부여와 송신은 전용 프록시의 집합에서 제어합니다. 이렇게 하면 애플리케이션 코드의 취약점이 이러한 컨트롤에 영향을 주지 못하게 됩니다. 원격 코드를 실행하려면 애플리케이션 로직을 수정하는 기능이 있어야 할뿐 아니라 기본 호스트를 손상시키고 Docker 컨테이너 경계를 우회해야 합니다. 그 대신 호스트 수준의 침입 감지에서 불일치를 플레그합니다.

이러한 프록시는 서비스의 의도된 동작에 따라 송신 동작을 제한합니다. 웹훅을 송신하거나 다른 마이크로서비스와 통신할 필요가 없는 서비스는 금지됩니다.

데이터 암호화

Atlassian Cloud 제품의 고객 데이터는 공용 네트워크를 통해 전송될 때 TLS 1.2 이상과 PFS(Perfect Forward Secrecy)를 사용하여 암호화하여 무단 공개 또는 수정을 방지할 수 있습니다. Atlassian에서 TLS의 구현은 브라우저에서 지원하는 강력한 암호 및 키 길이를 적용합니다.

Jira Cloud, Jira Service Management Cloud, Bitbucket Cloud, Confluence Cloud, Jira Product Discovery, Statuspage, Opsgenie 및 Trello에 고객 데이터 및 첨부 파일을 보관하고 있는 서버의 데이터 드라이브는 미사용 시 전체 디스크에 업계 표준인 AES-256 암호화를 사용합니다.

PII transmitted using a data-transmission network are subject to appropriate controls designed to ensure that data reaches its intended destination. Atlassian's internal Cryptography & Encryption Policy sets out the general principles for Atlassian's implementation of encryption & cryptography mechanisms to mitigate the risks involved in storing PII and transmitting it over networks. The type of encryption algorithm used to encrypt PII must take into account the classification level of the PII in accordance with Atlassian's internal Data Security & Information Lifecycle Management. To learn more about how we collect, share, and use customer data, refer to our privacy page.

To keep up to date on additional data encryption capabilities, see our cloud roadmap.

키 관리

Atlassian은 AWS KMS(Key Management Service)를 사용하여 키를 관리합니다. 데이터의 개인 정보 보호를 보장하기 위해 KMS는 이러한 키의 생성자이며 비밀 스토리지입니다. AWS는 기존 내부 유효성 검사 프로세스의 일부로 매년 정기적으로 암호화, 암호 해독 및 키 관리 프로세스를 검사하고 확인합니다. 각 키에 소유자를 할당하며, 소유자는 키에 적절한 수준의 보안 컨트롤을 적용하는지 확인을 담당합니다. Atlassian에서 관리하는 키는 역할 또는 고용 상태가 바뀜에 따라 교체됩니다.

Atlassian은 봉투 암호화도 활용합니다. AWS에는 Atlassian이 절대 볼 수 없는 마스터 키가 있으며 키 암호화 또는 암호 해독 요청에는 올바른 AWS 역할과 권한이 필요합니다. 봉투 암호화를 사용하여 개별 고객을 위한 키를 만들거나 생성하는 경우 데이터 스토리지를 통해 다양한 유형의 데이터에 대해 서로 다른 데이터 키를 사용할 수 있습니다. 또한 다른 AWS 리전에서 백업 데이터 키를 제공하는 내부 애플리케이션 계층에 대한 암호화 접근 방식이 있습니다. 키는 매년 자동으로 교체되며 같은 데이터 키는 100,000개 이상의 데이터 요소에는 사용되지 않습니다.

곧 AWS KMS에서 자체 관리 키로 Cloud 제품 데이터를 암호화할 수 있는 BYOK(Bring Your Own Key) 암호화를 제공할 것입니다. BYOK를 사용하면 키 관리를 완벽하게 제어할 수 있으며 최종 사용자와 Atlassian 시스템 모두에 대해 언제든지 액세스 권한을 부여하거나 철회할 수 있습니다.

모든 키 사용에 대한 로그를 제공하기 위해 AWS KMS를 AWS 계정의 AWS CloudTrail과 통합할 수 있습니다. 이 솔루션을 사용하면 데이터베이스, 파일 스토리지, 내부 캐시 및 이벤트 큐와 같이 애플리케이션 전체의 다양한 계층에서 데이터를 암호화할 수 있습니다. 프로세스 전반에서 제품 사용성에 미치는 영향은 없습니다.