본 페이지는 편의를 위해 제공되는 번역본입니다. 영어본이 우선합니다. 영어로 보기

규제 정보

보안 및 무결성

당행 금융 거래의 보안 및 무결성

당행과 같은 은행은 업무 영역별로 특화된 서버 인프라를 사용합니다. 구조적 요건과 금융 규제에 따라 주요 서버 유형은 다음과 같습니다.

1. 코어 뱅킹 서버

이 서버들은 고객 계좌, 거래 및 컴플라이언스를 관리하는 핵심 운영 기반을 이룹니다.

  • 거래 처리 서버: 실시간 지급 승인, 사기 방지 점검 및 결제를 수행합니다(예: SWIFT, SEPA).
  • 계좌 관리 서버: 계좌 수명주기 이벤트(개설/해지), 이자 계산 및 유동성 모니터링을 처리합니다.
  • 규제 컴플라이언스 서버: AML(자금세탁방지) 점검, 감사 추적 및 보고(예: IFRS, GDPR)를 자동화합니다.

2. 원장 서버

불변의 재무 기록 유지를 담당합니다:

  • 총계정원장 서버: 계정 전반에 걸친 복식부기를 추적하여 IFRS와 같은 회계 기준의 준수를 보장합니다.
  • 분산원장기술(DLT) 서버: 국경 간 결제, KYC 확인 및 변조 방지 거래 로그를 위한 블록체인 기반 시스템.

3. 외부 통신 서버
외부 기관과의 안전한 상호 연결을 지원합니다.

  • EBICS 서버: SEPA 결제를 위한 전자 은행 인터넷 통신 표준(EBICS)을 관리하며, 독일, 프랑스, 스위스에서 널리 사용됩니다.
  • 호스트 투 호스트(H2H) 서버: 대량 기업 거래(예: 일괄 급여 처리)를 위한 직접 SFTP/FTPS 연결.
  • API 게이트웨이 서버: 실시간 지급 개시 및 계좌 통합 조회를 위한 RESTful 인터페이스를 제공합니다(OAuth2/mTLS를 통해 보안 확보).
  • Swift 인터페이스 서버: 은행 간 메시지 교환을 위해 은행을 Swift 네트워크에 연결합니다(SCORE는 기업의 접속을 위한 Swift의 폐쇄 이용자 그룹이며, 서버 유형이 아닙니다).

4. 데이터베이스 서버
정형 금융 데이터의 중앙 저장소:

  • 고객 데이터 서버: KYC 서류, 거래 내역 및 행태 분석 데이터를 저장합니다.
  • 상품 카탈로그 서버: 대출, 모기지, 예금 금리 등의 상품을 관리합니다.

5. 보안 및 인프라 서버
시스템 무결성과 규제 준수를 보장합니다.

  • 하드웨어 보안 모듈(HSM) 서버: 전자서명 및 SSL/TLS 암호화에 사용되는 암호 키를 안전하게 보호합니다.
  • 방화벽/VPN 서버: 네트워크 분리를 적용하고 직원의 원격 접속을 안전하게 보호합니다.
  • 재해 복구 서버: 장애 발생 시 업무 연속성을 위한 백업 시스템을 구동합니다.

현대의 은행은 확장성을 위해 온프레미스 코어 서버와 클라우드 기반 DLT 노드를 결합한 하이브리드 아키텍처를 도입하는 경우가 많습니다. 예를 들어, 은행은 IBM의 온프레미스 코어뱅킹 서버와 AWS에서 호스팅되는 원장 서버를 함께 사용하여 실시간 대사를 수행할 수 있습니다. 이러한 모듈형 접근 방식은 규제 준수, 성능 및 혁신 간의 균형을 이룹니다.

은행은 효율성을 위한 서버 통합과 보안 및 컴플라이언스를 위한 격리 유지 사이에서 균형을 이루어야 합니다. 아래는 기술적 제약과 업계 관행에 따라 통합 가능한 서버와 통합이 불가능한 서버를 구분하여 설명한 것입니다.
통합 가능한 서버
1. 웹/애플리케이션 서버

  • 결합 방식: 가상화(VMware, KVM) 또는 컨테이너화(Docker/Kubernetes)
  • 예시: 로드 밸런싱이 적용된 하이퍼바이저 클러스터에서 여러 뱅킹 포털(리테일, 기업, 모바일)을 호스팅하는 경우.

2. 데이터베이스 서버

  • 조합 방식: 멀티테넌트 클라우드 데이터베이스(AWS RDS, Azure SQL)
  • Oracle/MS SQL 기반 핵심 뱅킹 데이터베이스는 하이브리드 클라우드 환경에서 PostgreSQL/MongoDB 기반 분석 시스템과 공존할 수 있습니다.

3. 외부 통신 게이트웨이

  • 결합 방식: 통합 API 게이트웨이(Apigee, MuleSoft)
  • EBICS, SWIFT 및 SFTP 서비스는 프로토콜별 마이크로서비스와 함께 공유 인프라에서 운영될 수 있습니다.

4. 재해 복구 서버

  • 결합 방식: 액티브-액티브 지리적 이중화
  • 코어 뱅킹 복제본과 백업 원장 서버는 재해 복구(DR) 클러스터를 공유할 수 있습니다.

5. 미들웨어 서버

  • 통합 방식: 엔터프라이즈 서비스 버스(ESB)
  • 결제 라우팅, 컴플라이언스 점검 및 통화 환전 서비스를 IBM Integration Bus/SAP PI에 통합했습니다.

격리 상태를 유지해야 하는 서버
1. 핵심 거래 처리 서버

  • 사유: 물리적으로 또는 엄격한 분리 체계를 통해 환경을 분리하면 PCI DSS 및 SOC 2 통제의 적용 범위가 축소됩니다
  • 예시: CICS 트랜잭션 모니터를 구동하는 IBM zSystems는 다른 워크로드와 하드웨어를 공유할 수 없습니다.

2. 하드웨어 보안 모듈(HSM) 서버

  • 사유: FIPS 140-2/140-3 레벨 3은 변조 방지 전용 하드웨어를 의무화하고 있습니다
  • 구현: 디지털 서명 및 암호화 키를 처리하는 Thales/Gemalto HSM.

3. 실시간 원장 시스템

  • 사유: 복식부기는 원자성을 요구합니다
  • 예시: 직접 연결형 NVMe 스토리지를 갖춘 Oracle Financial Services 원장 서버.

4. 규제 보고 서버

  • 사유: 감사 로그는 변경으로부터 보호되어야 하며 GDPR 및 AML 관련 법령이 요구하는 기간 동안 보관되어야 합니다. 분리 보관은 이를 입증하기에 더 용이합니다.
  • 구성: MiFID II/FATCA 보고를 위한 독립된 SQL Server 인스턴스.

5. ATM/POS 승인 시스템

  • 사유: 99.999% 가동률 SLA 및 네트워크 분리 요건
  • 아키텍처: 이중화된 Fibre Channel SAN을 갖춘 IBM Power Systems.

기술적 제약:

  • 대용량 코어 뱅킹 시스템에는 전용 고대역폭 네트워크 연결이 필요합니다
  • PCI DSS는 저장된 카드 번호(PAN)를 판독할 수 없도록 처리하고 카드 소지자 데이터 환경을 분리할 것을 요구합니다
  • Swift 고객 보안 프로그램(CSP)은 Swift 인프라를 보호된 보안 구역 내에 두도록 요구합니다.

당행은 핵심 시스템, HSM 및 원장 시스템은 완전히 분리된 상태로 유지하면서 비핵심 서버(웹/앱/미들웨어)의 80%를 성공적으로 통합하였습니다.

클라우드 환경에서 원장 서버를 보호하려면 금융 데이터의 민감성에 맞춘 다층적 보호 체계가 필요합니다. AWS 보안 모범 사례와 은행 특화 구현 방식을 바탕으로 한 체계적인 접근 방식은 다음과 같습니다.

1. 불변 원장 기술
모든 거래에 대한 암호학적 검증 기능을 갖춘 전용 원장 데이터베이스를 사용합니다.

  • 암호학적 체인 구조: 각 거래는 해시 처리되어 직전 기록과 연결되며, 변경이 불가능한 감사 추적을 형성합니다.
  • 내장된 무결성 검증 기능: 데이터베이스가 자체 이력을 자동으로 검증하여 위변조를 방지합니다.
  • SQL 유사 질의: 기존 금융 시스템과의 호환성을 유지하면서 블록체인과 유사한 보안을 더합니다.

2. 네트워크 격리

  • VPC 아키텍처: 원장 서버는 공용 인터넷 접속이 없는 프라이빗 서브넷에 배치합니다.
  • 보안 그룹: 인바운드 트래픽을 사전 승인된 IP 대역에서 오는 특정 포트(예: PostgreSQL/Aurora)로 제한합니다.
  • VPC 엔드포인트: 원장 서버와 S3/KMS 같은 서비스 간의 안전한 통신을 위해 AWS PrivateLink를 사용하여 공용 웹에 노출되지 않도록 합니다.

3. 암호화

  • 저장 시: AWS KMS가 관리하는 키로 Amazon Aurora의 원장 데이터를 암호화하며, 키는 자동으로 교체됩니다.
  • 전송 중 데이터: 모든 클라이언트-서버 및 서비스 간 통신에 TLS 1.3을 적용합니다.
  • 클라이언트 측 암호화: 저장 전에 AWS Encryption SDK를 사용하여 민감한 필드(예: 계좌 잔액)를 사전 암호화합니다.

4. 접근 통제

  • IAM 역할: 세분화된 권한(예: 삽입 전용 역할)을 부여하여 우발적이거나 악의적인 데이터 삭제를 방지합니다.
  • 임시 자격 증명: 유지보수 기간 중 시간 제한이 있는 접근 권한에는 AWS STS를 사용합니다.
  • 다중 인증(MFA) 적용: 루트 및 관리자 계정에는 하드웨어 토큰(YubiKey)을 요구합니다.

5. 모니터링 및 감사

  • 실시간 알림: 비정상적인 거래 패턴(예: 100만 유로를 초과하는 이체)에 대해 알림이 발생하도록 AWS CloudWatch를 구성합니다.
  • 활동 로그: SIEM 도구와 연동된 AWS CloudTrail을 통해 모든 원장 변경 사항을 추적합니다.
  • 자동화된 감사: 매주 AWS Config 규칙을 실행하여 암호화 상태 및 네트워크 정책을 확인합니다.

6. 컴플라이언스 및 거버넌스

  • 영역 기반 분리: AWS Organizations를 사용하여 DEV/TEST/PROD 원장 환경을 분리합니다.
  • 자동화된 보고서: AWS Audit Manager를 통해 PCI DSS/GDPR 컴플라이언스 보고서를 생성합니다.
  • 제3자 감사: AWS가 승인한 파트너를 통해 연 1회 침투 테스트를 실시하도록 일정을 수립하십시오.

7. 재해 복구

  • 리전 간 복제: 프랑크푸르트 및 스톡홀름 AWS 리전에 암호화된 원장 복제본을 유지합니다.
  • 특정 시점 복구: 연속 백업을 활성화하면 보존 기간(최대 35일) 내의 임의의 시점(초 단위)으로 데이터를 복원할 수 있습니다.
  • 에어갭 백업: 분기별 원장 스냅샷을 AWS Backup Vault에 7년간 보관합니다.
보안 및 무결성 - 금융 데이터의 다층적 보호

악성 입력이 재해복구(DR) 서버로 전파되는 것을 방지하기 위하여 은행은 백업을 분리하고 엄격한 접근 통제를 시행하며 데이터 무결성을 검증하는 다층적 보안 전략을 적용합니다. 주요 조치에 대한 기술적 내용은 다음과 같습니다.
1. WORM(Write-Once-Read-Many) 구성을 통한 변경 불가능한 백업

  • 목적: 랜섬웨어가 백업 데이터를 변조하거나 암호화하지 못하도록 차단합니다.

구현 방식: AWS S3 Object Lock 또는 Azure Blob Immutable Storage를 사용하여 정해진 보존 기간 동안 삭제 및 변경을 방지합니다. 백업 파일에 암호화 해시(SHA-256)를 적용하여, 변조가 발생하면 해시가 무효화되어 경보가 작동하도록 합니다.
2. 에어갭 및 오프라인 복제

  • 네트워크 격리: 재해 복구(DR) 서버는 인바운드 인터넷 접속이 없는 별도의 VPC/VLAN에 배치합니다. AWS Storage Gateway 또는 Azure Site Recovery와 같은 도구를 통해 단방향 복제(기본 시스템 → DR)를 사용하고 역방향 동기화는 차단합니다.
  • 물리적 에어갭: 핵심 시스템의 경우, 예정된 복제 시간대에만 연결되는 테이프 백업 또는 오프라인 저장소를 유지하십시오.

3. 제로 트러스트 접근 통제

  • 인증: 모든 DR 관리 인터페이스(예: AWS SSO, Azure AD 조건부 액세스)에 대해 MFA를 의무화합니다. IAM 역할에는 최소 권한 원칙에 따른 권한(예: `s3:GetObject`만 허용)을 부여합니다.
  • 네트워크 보안: 복제 트래픽을 IPsec VPN 터널 또는 AWS Direct Connect/Azure ExpressRoute로 제한합니다. Snort 또는 Suricata와 같은 침입 탐지 시스템(IDS)을 구축하여 복제 채널을 모니터링합니다.

4. 데이터 무결성 검증

  • 복제 전 점검: 복제에 앞서 ClamAV 또는 CrowdStrike Falcon과 같은 도구로 원본 데이터의 악성코드 감염 여부를 검사합니다. 전송 전후의 체크섬을 비교하여 변조 여부를 확인합니다.
  • 복제 후 감사: AWS Config 또는 Azure Policy를 사용하여 재해복구 서버에 암호화 및 접근 정책을 적용하십시오. 스크립트(예: `sha256sum` 검증)를 통해 일일 무결성 점검을 예약하십시오.

5. 논리적으로 분리된 환경

6. 자동 장애 조치(Failover) 테스트

  • 모의 공격: Chaos Monkey와 같은 도구를 사용하여 랜섬웨어 감염을 모의하고 재해복구(DR) 서버의 복원력을 검증합니다. 훈련 과정에서 복구 시간 목표(RTO)와 복구 시점 목표(RPO)를 측정합니다.
  • 포렌식 분석: 복제 이상 징후를 추적할 수 있도록 VPC Flow Logs와 CloudTrail 이벤트를 90일간 보관하십시오.

불변 백업의 구현은 랜섬웨어, 우발적 삭제 및 컴플라이언스 위반으로부터 데이터를 보호하는 데 필수적입니다. AWS, Veeam, Azure 등 업계 표준과 도구를 기준으로 한 모범 사례는 다음과 같습니다.
1. 스토리지 계층에서 불변성 적용

  • AWS의 S3 Object Lock, Azure Immutable Blob Storage 또는 Veeam Hardened Repositories를 통한 오브젝트 스토리지로 WORM(Write-Once-Read-Many) 구성을 사용하십시오.
  • 관리자에 의한 경우를 포함하여 조기 삭제 또는 변경을 방지하도록 보존 잠금(retention lock)을 활성화하십시오.

2. 3-2-1-1 백업 전략 채택

  • 데이터 사본 3부(원본 + 백업 2부)
  • 2종의 저장 매체(예: 디스크 + 클라우드)
  • 원격지 사본 1부(지리적으로 분리된 장소)
  • 변경 불가능한 사본 1부(망분리 또는 WORM 지원).

3. 엄격한 접근 통제 시행

  • 역할 기반 접근 통제(RBAC): IAM 역할을 통해 권한을 제한합니다(예: AWS Backup Vault 접근 정책).
  • 다요소 인증(MFA): 백업 관리 인터페이스에 대해 의무적으로 적용합니다(예: Azure AD Conditional Access).
  • 네트워크 격리: 백업은 공용 인터넷 접근이 차단된 비공개 서브넷/VPC에 보관합니다.

4. 데이터의 종단 간 암호화

  • 저장 시: AES-256 또는 KMS가 관리하는 키(AWS, Azure)를 사용합니다.
  • 전송 구간: 복제 채널에는 TLS 1.3 적용.
  • 클라이언트 측 암호화: 민감한 항목은 백업 이전에 사전 암호화합니다(예: 사용자가 관리하는 키를 사용하는 Veeam의 AES-256).

5. 보관 및 검증의 자동화

  • 보존 정책: RPO/RTO를 정의하고 수명주기 규칙을 자동화합니다(예: AWS Backup Vault의 7년 보존).
  • 체크섬 검증: 복제 전후의 무결성을 확인합니다(예: SHA-256 해싱).
  • 정기 감사: AWS Config 또는 Veeam SureBackup과 같은 도구를 사용하여 복원 테스트를 수행합니다.

6. 하이브리드 환경을 위한 다층 보안

7. 컴플라이언스 확보 및 불가역성 보장

  • 테스트 완료 후 불변성 설정을 잠그십시오(예: Azure의 "활성화 및 잠금" 상태).
  • 규정 준수: AWS Audit Manager와 같은 도구를 활용하여 GDPR, HIPAA 또는 SOX에 부합하도록 대응하십시오.
  • 제3자 감사: 연간 침투 테스트를 일정에 반영하십시오(예: AWS 승인 파트너 활용).

AWS 및 Veeam을 활용한 워크플로 예시
1. 1차 백업: Object Lock이 적용된 S3 버킷으로 Veeam Backup & Replication 백업.
2. 복제: AWS DataSync를 통해 보조 리전으로 복제(프랑크푸르트 → 스톡홀름).
3. 검증: 일일 CloudTrail 로그 점검 및 분기별 복구 훈련.
4. 보존: KMS 암호화를 적용한 90일간의 변경 불가 보존 기간.

불변성 기능, 접근 통제 및 하이브리드 이중화를 결합함으로써, 조직은 컴플라이언스 요건을 충족하면서 랜섬웨어에 대한 복원력을 갖춘 백업을 구현할 수 있습니다.