Jira DC 제품의 SSO 연동 및 DR 구축 방안 사례

1. Jira DC 제품의 SSO 연동 방식과 사례

1.1 SAML 2.0 연동 아키텍처 및 메커니즘

Jira Data Center는 외부 IDP(Identity Provider)와 SAML 2.0 프로토콜을 통해 인증을 위임한다.

(SAML 2.0는 세계 표준)

• 주요 용어 정의:
  • Service Provider (SP): Jira Data Center (인증을 요청하는 주체)
  • Identity Provider (IdP): Google, Okta, Azure AD (인증을 수행하는 주체)
  • SAML Assertion: 인증 성공 후 IdP가 SP에게 전달하는 보안 토큰 (XML 기반)
• 인증 흐름 (Browser-based SSO):
  1. 사용자가 Jira 접속 시 로그인이 필요하면 Jira는 IdP의 SSO URL로 리다이렉트합니다.
  2. IdP는 사용자의 자격 증명(ID/PW, MFA 등)을 확인합니다.
     (보안이 중요한 경우엔 KeyClock 같은 오픈소스를 통해 IdP서버를 직접 구축할 수 있다.)
  3. 인증 성공 시 IdP는 사용자 정보를 담은 SAML Assertion을 생성하여 사용자의 브라우저를 통해 Jira로 전송합니다.
  4. Jira는 수신된 Assertion의 서명을 검증하고 사용자를 로그인 처리합니다.

1.2 Google IDP 연동 방법

https://support.atlassian.com/jira/kb/configure-saml-sso-for-jira-data-center-with-google-idp/

1.3 REST API를 활용한 SSO 관리 및 테스트 자동화

왜 RestAPI를 활용해 SSO 관리 를 해야하나?

• Web UI 접근이 불가능한 상황
  (https://confluence.atlassian.com/enterprise/saml-single-sign-on-for-atlassian-data-center-applications-857050705.html ui를 통한 SSO관리법)
  • 장애 발생: SAML 인증서가 만료되면, Jira는 모든 로그인 시도를 거부합니다.
  • 문제: Jira 관리자 역시 보통 SSO(SAML)를 통해 로그인하도록 설정되어 있습니다.
  • 결과: 관리자가 인증서를 교체하기 위해 관리자 화면(Web UI)에 들어가고 싶어도 로그인을 못 해서 못 들어가는 황당한 상황이 발생합니다.
• 인증서 갱신을 자동화 해야 운영 관리 리스트가 줄어든다.

예시

• 상태 확인: GET /rest/authconfig/1.0/idps
  • 용도: 현재 Jira에 등록된 인증서(certificate 필드)의 값과 마지막 업데이트 시간(last-updated)을 확인합니다.
  • 갱신 상황 활용: 운영자는 이 API를 주기적으로 호출하여, 현재 등록된 도장(인증서)이 구형인지 신형인지 체크할 수 있습니다.
• 인증서 교체: PATCH /rest/authconfig/1.0/idps/{id}
  • 용도: 기존 설정은 그대로 두고 인증서 값(certificate)만 쏙 갈아 끼울 때 사용합니다.
  • 갱신 상황 활용: 구글(IdP)에서 새 도장을 발급받으면, SSH로 서버에 들어갈 필요 없이 이 API에 새 인증서 텍스트를 담아 보내면 즉시 갱신됩니다.

2. Jira DC 제품의 DR (Disaster Recovery) 구축 방안

2.1 DR 개요

Jira Data Center 제품은 재해 발생 시 별도 사이트에 준비된 스탠바이 인스턴스로 서비스를 복구하는 Cold Standby 방식의 DR 전략을 권장한다.
이를 위해 RPO/RTO를 사전에 정의하고, 애플리케이션·데이터베이스·파일·네트워크를 포함한 전체 구성을 동일하게 준비해 두어야 한다.

2.2 RPO / RTO 정의

• RPO(Recovery Point Objective): 장애 발생 후 Jira 이슈·구성 데이터가 어느 시점까지 보존돼야 하는지에 대한 목표이며, DB/파일 복제 주기를 설계할 때 기준이 된다.
• RTO(Recovery Time Objective): DR 선언 이후 스탠바이 Jira 인스턴스를 얼마 만에 서비스 가능 상태로 기동할 것인지에 대한 목표이며, DR 전환 절차와 자동화 수준을 결정한다.

2.3 DR 아키텍처 구성 요소

• 애플리케이션(Jira DC 노드)
  • DR 사이트에는 운영 사이트와 동일 버전의 Jira Data Center를 설치하고, 노드 수와 JVM 옵션, server.xml 등의 설정을 최대한 동일하게 유지한다.
  • DR 모드 사용 시 jira-config.properties 설정과 라이선스, SSO/역할 매핑 등 애플리케이션 레벨 설정도 동일하게 맞춰야 한다.
• 데이터베이스(DB)
  • Jira 데이터의 소스 오브 트루스로, DB 레벨의 동기/비동기 복제를 구성해 DR 사이트 DB가 RPO를 만족하도록 지속적으로 업데이트되도록 한다.
  • 복제는 각 DB 제품의 네이티브 기능(스트리밍 복제, 미러링 등)을 사용하며, DR 전환 전에는 복제 상태와 라그(lag)를 반드시 점검한다.
• 파일(Jira home / shared home)
  • 첨부파일, 아바타, Lucene 인덱스 스냅샷, 사용자 설치 앱 파일 등은 Jira의 File Replication 기능 또는 스토리지 수준 복제를 통해 DR용 secondary 위치로 비동기 복제한다.
  • Jira는 primary home의 변경 사항을 모니터링 후 큐에 적재해 secondary 위치로 재생하며, 첨부/아바타/인덱스는 거의 실시간, 앱 파일은 큐가 60초 이상 idle일 때 복제되는 특성이 있어 복구 시점 계산에 반영해야 한다.

• 설치 디렉터리 및 설정 파일
  • Jira 설치 디렉터리의 server.xml, setenv.sh, 커넥터 설정 등은 DR 파일 복제 대상이 아니므로, 운영 인스턴스를 기준으로 DR 인스턴스에 수동으로 동기화해야 한다.
  • localhome/dbconfig.xml의 DB 커넥션 정보는 DR용 DB로 분리해 두고, DR 테스트 시 충돌이 없도록 주의한다.
• 네트워크 / 접근 경로
  • L4, DNS, HTTP Proxy(예: Nginx, Apache, Load Balancer)에서 운영/DR 사이트로의 라우팅을 전환할 수 있는 구성을 준비해 두고, DR 전환 시 이 경로를 DR 인스턴스로 스위칭한다.
  • 사내 SSO, 메일 서버, 기타 연동 시스템과 DR 사이트 간 네트워크 링크도 사전에 검증해야 한다.

2.4 DR 운영 절차