보안 관행

Atlassian의 팀

대부분의 기업도 마찬가지겠지만, Atlassian은 보안 팀을 아주 자랑스럽게 생각합니다. 업계에서 최고로 유능한 인재를 영입하여 팀으로 성장시켰다고 믿습니다. Atlassian의 보안 팀은 샌프란시스코에 위치한 CISO가 이끌며 일부 원격 팀원을 포함하여 시드니, 암스테르담, 벵갈루루, 오스틴, 마운틴뷰, 샌프란시스코 및 뉴욕 사무소에 근무하는 130명 이상의 팀원으로 이루어져 있습니다. Atlassian이 보안에 우선 순위를 둠에 따라 보안 팀은 계속 성장하고 있습니다. 다음을 포함하여 여러 팀으로 나눠져 있습니다.

• 제품 보안 – 제품 및 플랫폼의 보안 담당
• 에코시스템 보안 – Marketplace 및 애드온의 보안 담당
• 탐지 및 대응 – 보안 인시던트 탐지 및 대응 담당
• 레드 팀 - 공격자 에뮬레이션 및 탐지 및 대응 적용 담당
• 보안 아키텍처 – 제품 및 플랫폼의 보안 요구 사항 정의 담당
• 기업 보안 – 기업 네트워크 및 애플리케이션과 관련된 내부 보안 담당
• 신뢰 - 고객 기대치를 추적 및 대응을 담당하고 프로세스 및 관행에 투명성 제공
• 개발 및 SRE – 보안 팀을 위한 도구 제작 및 실행 담당
• 인식 및 교육 - 직원 및 파트너에게 안전하게 작업을 수행하는 방법 교육

보안 팀은 계속 확장하고 있으며 Atlassian의 모든 직원은 더 나은 보안을 달성하기 위한 노력에 동참하고 Atlassian은 모든 직원에게 근무하는 동안 이 점을 분명히 알리고 있습니다. Atlassian은 클라우드 보안에서 동종업계를 이끌고, 클라우드 보안에 대한 고객의 모든 요구 사항을 충족하며, 모든 업계 보안 기준 및 인증에서 요구 사항을 뛰어넘고, 고객 데이터를 보호하는 방법에 대한 세부 사항을 자랑스럽게 알린다는 목표를 가지고 있습니다. Atlassian에서 일하는 모든 직원에게 Atlassian의 목표 및 비전을 명확하게 알립니다.

Atlassian이 보안을 지원하기 위해 사용하는 추가 프로그램

보안의 기본 사항에 중점을 두는 동시에, Atlassian에서는 보안에 대한 접근 방식이 광범위하고 사전 예방적이라는 점을 보장하기 위해 다양한 프로그램을 갖추고 있습니다. 여기에는 다음이 포함됩니다.

지속적으로 보안 프로그램 개선

Atlassian은 보안 프로그램이 항상 최첨단이며 업계에서 동종업계를 이끌도록 만들기 위해 노력합니다. 그러려면 보안에 대한 현재의 접근 방식을 계속 평가(동종업체와 비교 포함)하고 개선의 여지를 파악해야 한다는 점을 잘 알고 있습니다.

이런 목적을 가지고 Atlassian은 독립적인 보안 컨설팅 회사를 통해 보안 프로그램에 대해 수많은 성숙도 평가를 실시했으며 앞으로도 실시할 예정입니다. 2020년에는 전반적인 신뢰 및 보안 프로그램에 대해 동종업계 평가도 수행했습니다. 주요 권장 사항 등 프로세스의 결과를 사용하여 격차 및 개선의 여지를 파악합니다.

또한 제품 보안 및 탐지 및 대응과 같이 다양한 보안 전반에 걸쳐 내부 개선을 이끄는 일련의 프로그램을 정의했습니다. 보안 관리 팀을 통해 검토하는 각 프로그램을 지원하기 위해 여러 메트릭을 정의했습니다. 이러한 메트릭을 사용하여 각 핵심 역량에서 개선할 부분을 파악하고 지정합니다.

추가 정보

이 문서에서는 보안에 대한 Atlassian의 접근 방식의 포괄적인 개요를 제공하며, 보안 프로그램과 관련된 자세한 내용은 Atlassian Trust Center에서 확인할 수 있습니다. 또한 이용 가능한 보안 프로그램의 여러 부분을 자세히 설명하는 다음과 같은 다양한 전용 웹 페이지 및 백서가 준비되어 있습니다.

• Atlassian이 고객 데이터를 관리하는 방법
• 외부 보안 테스트에 대한 Atlassian의 접근 방식
• 보안 인시던트 관리에 대한 Atlassian의 접근 방식
• 취약성 관리에 대한 Atlassian의 접근 방식
• 클라우드 보안 공동 책임
• Atlassian Trust Management System
• Atlassian 보안 및 기술 정책

제로 트러스트를 통한 네트워크 액세스 보호

Atlassian은 제로 트러스트라는 개념을 통해 기업 네트워크, 내부 애플리케이션 및 클라우드 환경에 대한 액세스를 보호합니다. 간단히 말해, 제로 트러스트의 핵심 원리는 “절대 신뢰하지 말고 항상 확인하자”입니다.

제로 트러스트는 사용자의 인증에만 의존하여 사용자가 네트워크의 리소스에 액세스할 수 있는지 여부를 판단하는 기존의 네트워크 보안 접근 방식에서 탈피했습니다. 그러한 접근 방식은 신뢰할 수 없는 안전하지 않은 장치가 잠재적으로 보안을 손상하는 위험을 초래합니다. 따라서 많은 조직이 모바일 장치 관리 기술과 같은 접근 방식을 사용하거나 네트워크 수준에서 알려진 장치 목록에 대한 액세스를 제한하여 신뢰할 수 있는 장치만 네트워크에 액세스할 수 있는 모델로 이동하기 시작했습니다.

이러한 접근 방식은 유용하지만 세분화되어 있지 않습니다. Atlassian의 제로 트러스트 접근 방식은 사용자의 인증 자격 증명을 기반으로 사용자가 네트워크의 리소스 및 서비스에 액세스할 수 있는지 여부를 효과적으로 판단할 뿐만 아니라, 위치와 관계없이 사용자 장치의 보안 포스처에 따라 리소스 수준별로 액세스를 거부하거나 허용하는 다양한 요인을 고려하는 동적 정책 결정도 수반합니다.

간단히 말해, Atlassian은 제로 트러스트가 작동하는 네트워크에서 리소스의 상대적 중요도 및 민감도를 기반으로 3개의 리소스 티어를 만들었습니다.

• 열린 티어 – 네트워크에 성공적으로 인증한 기업 사용자는 이러한 서비스에 액세스할 수 있습니다.
• 낮은 티어 – 인증된 기업 사용자가 신뢰할 수 있는 기업 장치(Atlassian이 소유하고 관리하는 장치) 또는 관리되는 BYOD(Atlassian의 MDM 프로그램에 등록된 개인 장치)에서 네트워크에 액세스하는 경우에만 이러한 리소스에 액세스할 수 있습니다.
• 높은 티어 – 이러한 리소스는 인증된 기업 사용자가 Atlassian이 발급한 기업 장치에서 액세스하는 경우에만 사용할 수 있습니다. 기업 네트워크에서 프로덕션 서비스에 액세스하려면 반드시 높은 티어 장치 및 SAML 인증을 사용해야 합니다.

시스템 및 서비스에 대한 액세스를 안전하게 관리

Atlassian has a well-defined process for provisioning (assigning or revoking) user access for all systems and services. We have an established workflow linking our HR management system and our access provisioning system. We use role-based access control based on predefined user profiles to ensure staff only have access appropriate to their job role. All user accounts must be approved by management prior to having access to data, applications, infrastructure or network components.

Supporting our ZeroTrust architecture, we control access to our corporate applications through a single-sign on platform. To access any of our applications, staff need to authenticate via this platform, including through the use of a second factor of authentication. Depending on the application, staff need to authenticate either using FIDO2 keys or via a mobile application authenticator provisioned to Atlassian staff – less secure authentication methods such as SMS and phone-based OTPs are not supported. Atlassian has adopted this approach to ensure our authentication process is highly resistant to phishing-based and man-in-the-middle attacks - any system that sends codes in a text message can be compromised by a skilled attacker.

엔드포인트 장치 보호

Corporate laptops

Devices that make up the Atlassian corporate fleet are configured to protect our data and reduce the risk of endpoint compromise. Under our Zero Trust program, devices that deviate from our approved standard are automatically prevented from accessing Atlassian systems.

Controls implemented on Atlassian corporate devices include:

• Central device management - Our MDM (Mobile Device Management) solution is responsible for enforcing security configurations (including CIS benchmarks), and deploying software/updates to all Atlassian-owned devices.
• Application control - Application control prevents the running of specific types of legitimate software (such as remote access solutions) that could compromise the security posture of our devices.
• Endpoint firewalls - Prevents local services from being exposed to the network.
• Anti-virus/endpoint detection & response (EDR) - Detects and blocks malware, collects log data and enables our security operations centre to respond to security incidents quickly.
• Secure browsing environment - All browsers used by staff are configured to prevent the installation or use of malicious extensions, and block known phishing sites or sites distributing malware.
• Disk encryption / screen locks - All devices are fully encrypted and set to lock after a period of inactivity.

Mobile / BYOD devices

Atlassian operates a BYOD (bring your own device) program for staff who wish to use their personal iOS or Android mobile devices to access corporate systems. All mobile devices must:

• Be enrolled in our MDM (Mobile Device Management) solution
• Have full disk encryption/screen locks enabled
• Be running the latest Android/iOS operating system

Mobile devices operating under the BYOD program have limited access to Atlassian systems and cannot access customer data.

시스템의 구성 관리

프로덕션 환경에 소프트웨어를 설치할 수 있는 엔지니어와 설계자의 수는 한정되어 있습니다. 대부분의 경우 소프트웨어 설치는 불가능합니다. 프로덕션 환경에서 구성 관리 도구를 활용하여 서버에 대한 변경 사항과 구성을 관리할 수 있습니다. 일관성을 보장하기 위해 이러한 시스템에 대한 직접적인 변경 사항은 그러한 구성 관리 도구를 통해 푸시하는 승인된 구성으로 덮어쓰도록 설정되어 있습니다. Atlassian은 표준 AMI(Amazon Machine Image)에 의존하며, AMI 또는 운영 체제에 대한 모든 변경은 표준 변경 관리 프로세스를 통해 이루어져야 하며, Atlassian은 예외 구성을 추적 및 보고하고, 서비스의 문제가 다른 서비스에 영향을 미치지 않도록 리소스 격리를 구현했습니다. 또한 PRGB(동료 검토/그린 빌드) 프로세스에 의존하여 여러 검토자가 구성 관리 도구를 통해 푸시된 구성 변경 사항을 승인할 수 있게 합니다. 모든 빌드는 암호화하여 서명하며 서명된 빌드만 프로덕션 환경에서 실행할 수 있습니다.

로그 활용

Atlassian은 SIEM 플랫폼을 사용하여 다양한 소스에서 로그를 집계하고 집계한 로그에 모니터링 규칙을 적용하여 의심스러운 활동을 표시합니다. 내부 프로세스는 이러한 경고를 심사하고, 자세히 조사하고, 적절히 에스컬레이션하는 방식을 정의합니다. 주요 시스템 로그를 각 시스템에서 전달하며 로그는 읽기 전용입니다. Atlassian 보안 팀은 보안 분석 플랫폼에 대한 알림을 만들고 손상의 지표를 모니터링합니다. SRE 팀은 이 플랫폼을 사용하여 가용성 또는 성능 문제를 모니터링합니다. 로그는 핫 백업에서 30일간, 콜드 백업에서 365일간 보관됩니다.

주요 시스템 로그는 내부 로그 분석 시스템과 침입 감지 시스템 모두에 결합됩니다.

로그는 '보안 위협 식별, 방지 및 대응 방법' 섹션에서 자세히 다루는 전체 인시던트 감지 및 응답 전략의 핵심 구성 요소입니다.

비즈니스 연속성 및 재해 복구 관리

Atlassian은 특히 내부적으로 똑같은 제품에 의존하기 때문에 제품의 복원력에 깊은 관심을 갖고 있습니다. Atlassian은 중단이 발생할 수 있음을 인식하고 있습니다. 따라서 중단에 대비하여 계획하고 중단이 발생할 경우 고객에게 미치는 영향을 최소화하면서 중단을 처리하는 프로세스를 구축하기로 했습니다. Atlassian의 비즈니스 연속성(BC) 및 재해 복구(DR) 프로그램은 그러한 목표를 충족하기 위해 수행한 다양한 활동을 포착합니다.

BC 및 DR 계획 활동에 리더십이 참여하여 복원력에 대한 책임이 모든 팀에 미치는지 확인하는 데 필요한 감독을 보장할 수 있습니다. Atlassian은 BC 및 DR 계획 활동을 수행하여 서비스의 ‘복구 시간 목표’(RTO) 및 ‘복구 지점 목표’(RPO) 분석을 통해 비용, 이익 및 위험 간의 적절한 균형을 이루기 위해 노력하고 있습니다. 이 분석을 통해 해당 복구 요구 사항을 기반으로 서비스를 그룹화할 수 있는 4개 티어 시스템을 확립했습니다. 이 접근 방식에 대한 자세한 내용은 Atlassian이 고객 데이터를 관리하는 방법 페이지에서 확인할 수 있습니다.

BC 및 DR 프로그램에는 다음 활동을 포함합니다.

1. 복원력 요구 사항을 충족하기 위한 이중화 조치 구축

2. 해당 이중화 조치를 테스트 및 확인

3. 테스트를 통해 BC 및 DR 조치를 지속적으로 개선

Atlassian은 클라우드 서비스 공급자가 제공하는 가용성 영역 및 리전과 같은 이중화 기능을 최대한 활용할 수 있도록 제품을 구축합니다.

Atlassian은 잠재적인 문제를 조기에 감지하는 것을 목표로 광범위한 지표를 지속적으로 모니터링합니다. 임계값을 위반하는 경우 인시던트 대응 프로세스를 통해 즉각적인 조치를 취할 수 있도록 그러한 지표를 기반으로 SRE(사이트 안정성 엔지니어) 또는 관련 제품 엔지니어링 팀에 알리는 경고를 구성합니다. SRE는 또한 DR 프로그램에 간격을 식별하는 데 있어서 중요한 역할을 하며 위험 및 규정 준수 팀과 협력하여 그러한 간격을 해소합니다. 각 팀에는 해당 팀과 관련된 재해 복구 측면을 감독하고 관리할 수 있도록 돕는 DR 챔피언도 있습니다.

Atlassian의 DR 테스트는 관련 프로세스 문서를 포함해 프로세스 및 기술 측면을 다룹니다. DR 테스트의 빈도는 각 서비스의 중요도 티어를 따릅니다. 예를 들어, 고객을 서비스하는 중요 시스템의 백업 및 복구 프로세스는 분기별로 테스트합니다. Atlassian은 시스템에서 수동 및 임시 장애 조치 테스트를 수행합니다. 이러한 테스트는 덜 복잡한 테이블탑 시뮬레이션 연습부터 더 복잡한 가용성 영역 또는 리전 장애 조치 테스트에 이르기까지 다양합니다. 테스트의 복잡성과 관계없이 Atlassian은 테스트 결과를 캡처 및 문서화하고, 가능한 개선 또는 격차를 분석 및 식별한 후 Jira 티켓을 활용해 테스트를 종료하여 전체 프로세스의 지속적인 개선을 보장하기 위해 노력하고 있습니다.

Atlassian은 연례 BIA(비즈니스 영향 평가)를 수행하여 중요 서비스와 관련된 위험을 평가합니다. BIA의 결과는 DR 및 BC 노력에 대한 전략을 추진하는 데 도움이 됩니다. 결과적으로 중요 서비스에 효과적인 DR 및 BC 계획을 수립할 수 있습니다.

서비스 가용성

위 조치 외에도 Atlassian은 자체 Statuspage 제품을 사용하여 고객에게 서비스 가용성 상태를 실시간으로 게시합니다. 따라서 제품에 문제가 있을 경우 고객은 Atlassian이 수행하는 조치를 바로 알 수 있습니다.

백업

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

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

Bitbucket의 경우 데이터는 다른 AWS 리전으로 복제되며 각 리전 내에서 매일 독립적인 백업이 수행됩니다.

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

물리적 보안

사무실의 물리적 보안 컨트롤은 온프레미스 및 클라우드에서 환경 전반에 걸쳐 강력한 물리적 보안을 구현하도록 보장하는 물리적 및 환경적 보안 정책에 따라 이루어집니다. 이 정책은 보안 작업 영역과 같은 영역을 다루며, 설치 위치와 관계없이 IT 장비를 보호하고, 건물 및 사무실에 대한 접근 권한을 해당 개인으로 제한하며, 물리적 출입구를 모니터링합니다. Atlassian의 물리적 보안 관행에는 업무 시간 중의 리셉션 근무, 방문자 등록 요구 사항, 모든 비공개 영역에서 배지 액세스가 포함되며, Atlassian은 사무실 건물 관리자와 협력하여 주 출입구와 화물 취급 영역 모두에서 업무 시간 후 진입 및 출구 지점의 접근 기록 및 비디오 녹화를 수행합니다.

Atlassian의 파트너 데이터 센터는 최소한 SOC-2를 준수합니다. 이러한 인증은 물리적 및 환경적 보안 및 보호를 포함한 다양한 보안 컨트롤을 다룹니다. 데이터 센터에 대한 액세스는 권한 있는 직원으로 제한되며 생체 인식 신원 확인 방안을 통해 확인합니다. 물리적 보안 조치에는 온프레미스 보안 요원, 폐쇄 회로 비디오 모니터링, 맨트랩, 추가 침입 보호 조치가 포함됩니다.

데이터 암호화

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

Data drives on servers holding customer data and attachments in Jira Software Cloud, Jira Service Management Cloud, Jira, Bitbucket Cloud, Confluence Cloud, Statuspage, Opsgenie, Trello, Loom, Compass and Rovo use full disk, industry-standard AES-256 encryption at rest. Please refer to the Atlassian Trust Roadmap to keep up to date with our platform updates.

키 관리

Atlassian은 AWS KMS(Key Management Service)를 사용하여 키를 관리합니다. AWS는 기존 내부 유효성 검사 프로세스의 일부로 매년 정기적으로 암호화, 암호 해독 및 키 관리 프로세스를 검사하고 확인합니다. 각 키에 소유자를 할당하며 소유자는 키에 적절한 수준의 보안 컨트롤을 적용하는지 확인하는 업무를 담당합니다.

테넌트 분리

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

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

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

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

TCS가 제공하는 컨텍스트는 고객 데이터와 상호 작용이 이루어지는 실질적 '렌즈''로서 작용하며, 이 렌즈는 항상 하나의 특정 테넌트에만 국한됩니다. 따라서 하나의 고객 테넌트가 다른 테넌트의 데이터에 액세스하지 않으며, 한 테넌트의 서비스가 자체 작업을 통해 다른 테넌트의 서비스에 영향을 미치지 않습니다.

클라우드 아키텍처에 대한 자세한 내용은 클라우드 지원 리소스의 일부분으로 제공됩니다.

고객 데이터 관리에 대한 책임 공유

Atlassian은 제공하는 애플리케이션, 애플리케이션이 실행되는 시스템 및 그러한 시스템을 호스팅하는 환경의 보안, 가용성 및 성능에 대한 책임을 집니다. 그러나 보안은 특히 다음 4가지 영역과 관련해서 Atlassian과 고객의 공동 책임입니다.

고객 데이터에 대한 액세스 제어

Atlassian은 모든 고객 데이터를 동일하게 민감한 데이터로 처리하며 이 데이터를 관리하는 엄격한 컨트롤을 구현했습니다. 또한 온보딩 프로세스 중에 내부 직원과 계약업체에 고객 데이터 처리의 중요성과 모범 사례를 다루는 인식 교육을 제공합니다.

Atlassian 내에서 권한 있는 Atlassian 직원만 애플리케이션에 저장된 고객 데이터에 액세스할 수 있습니다. 인증은 개별 암호로 보호된 공개 키를 통해 수행되며 서버는 Atlassian과 내부 데이터 센터에서 수신되는 SSH 연결만 허용합니다. 요청 및 검토되지 않는 한 모든 액세스는 권한 있는 그룹으로 제한되며 추가 인증에는 2FA가 필요합니다.

확립된 엄격한 인증 및 권한 부여 제어를 통해 글로벌 지원 팀은 유지 관리 및 지원 프로세스를 원활하게 수행할 수 있습니다. 호스팅된 애플리케이션과 데이터에는 애플리케이션 상태를 모니터링하고 시스템 또는 애플리케이션을 유지 관리하기 위해 또는 지원 시스템을 통해 고객이 요청할 경우 액세스할 수 있습니다. 고객에게는 동의 제어 확인 기능을 통해 고객 데이터에 액세스할 수 있는 지원 엔지니어와 관련하여 명시적으로 동의할 수 있는 옵션이 제공됩니다.

고객 데이터에 대한 무단 또는 부적절한 액세스는 보안 인시던트로 취급되며, 인시던트 관리 프로세스를 통해 관리합니다. 이 프로세스는 정책 위반이 관찰되는 경우 영향을 받는 고객에게 알리는 지침을 포함합니다.

데이터 보존 및 삭제

Atlassian은 사용자의 개인 정보 삭제 요청에 응답하고 Atlassian 계정을 보유한 최종 사용자가 개인 정보를 삭제하도록 돕기 위한 조항을 마련했습니다. 또한 고객이 Atlassian의 도구를 사용하여 데이터에 액세스하고 데이터를 가져오거나 내보낼 수 있도록 가져오기 및 내보내기 도구도 갖추고 있습니다.

고객 사이트는 고객의 현재 구독 기간이 종료되는 시점부터 15일 후에 비활성화됩니다. Atlassian은 고객의 현재 구독 기간이 종료되는 시점부터 15일(평가 사이트의 경우) 또는 60일(유료 구독 사이트의 경우) 동안 비활성화된 사이트의 데이터를 보관합니다. Jira의 경우 사용자가 이전에 구독한 모든 Jira 제품의 구독을 취소하는 경우에만 데이터가 삭제됩니다.

추가 정보는 보안 관행 페이지 또는 데이터 스토리지 FAQ에서 확인할 수 있습니다.