정보관리기술사 학습 노트
← 목록으로
보안·개인정보
#마이데이터#전송보안#CPO#접근관리#개인정보#132회
최종 업데이트 · 2026-10-01

마이데이터 전송 보안 (마이데이터 전송 보안 안내서, 2023.09)

1. 개요

가. 정의

마이데이터(본인신용정보관리업)에서 정보주체의 요구에 따라 개인(신용)정보를 기관 간 전송할 때 발생하는 위험을 통제하기 위한 관리적·기술적·물리적 안전조치 기준을 정리한 안내서로, 전송자(정보제공자)와 수신자(마이데이터 사업자) 양측에 보호책임자 지정·접근관리·전송 구간 보호·사고 대응 등을 공통으로 요구한다.

마이데이터의 본질은 은행·카드·보험·통신사 등 여러 기관에 흩어진 "내 정보"를 정보주체의 전송요구권에 근거해 한곳으로 모아 통합 조회·분석·추천에 활용하는 것이다. 종전에는 이용자가 각 기관 화면을 일일이 드나들며 정보를 확인했지만, 마이데이터는 표준 API를 통해 정보제공자의 데이터를 사업자가 직접 당겨오는 구조로 바꾸었다. 이 구조의 효용은 분명하지만, 그만큼 대량의 민감한 개인신용정보가 기관 사이를 상시·자동으로 오간다는 점이 근본 위험이다. 데이터가 이동하는 바로 그 순간이 유출·위변조·오전송·재사용의 위험 구간이므로, 전송 전 구간을 end-to-end로 통제하는 것이 마이데이터 신뢰의 전제가 된다.

나. 등장 배경 및 필요성

마이데이터가 2022년 전면 시행된 이후 참여 기관 수와 전송 트래픽이 폭증했고, 한 참여자의 보안 허점이 생태계 전체의 신뢰를 무너뜨릴 수 있는 구조가 되었다. API 한 건의 평균 전송량은 작아 보여도, 수백 개 기관이 수천만 명의 자산·소득·결제·대출 내역을 주기적으로 주고받으면 전체 노출면은 종전 개별 서비스와 비교할 수 없이 넓어진다. 특히 대상 정보가 자산·신용·소득 같은 재산 관련 민감정보라 유출 시 보이스피싱·대출 사기 등으로 즉시 금전 피해로 이어지고, 한 번 유출된 정보는 회수가 사실상 불가능하다.

또한 전송은 "주는 쪽"과 "받는 쪽"이 분리된 양자 행위이므로, 어느 한쪽만 안전해서는 의미가 없다. 전송자가 아무리 암호화해도 수신자가 접근통제를 소홀히 하면 수신 직후 데이터가 노출되고, 반대도 마찬가지다. 이에 감독·유관기관은 신용정보법·개인정보보호법의 안전성 확보조치 의무를 마이데이터 전송이라는 특수 맥락에 맞게 구체화하여, 전송자와 수신자가 동일한 수준의 보호책임을 지도록 기준을 통일한 것이 본 안내서다. 즉 안내서는 새로운 규제의 창설이 아니라, 기존 법적 의무를 전송 시나리오에 투영한 실무 해설·체크리스트의 성격을 가진다.

다. 특징

마이데이터 전송 보안은 일반적인 정보보호 조치와 비교해 세 가지 특징을 갖는다. 첫째, 상시성이다. 종전 서비스의 데이터 이동이 간헐적 배치였다면, 마이데이터는 정기 전송·수시 전송이 24시간 자동으로 일어나 통제도 상시 운영되어야 한다. 둘째, 표준화다. 참여 기관이 많아 개별 협의로는 보안을 맞출 수 없으므로, 표준 API와 공통 안전조치로 보안 수준을 평준화한다. 셋째, 정보주체 중심성이다. 모든 전송의 근거는 정보주체의 전송요구이므로, 요구의 진위·범위·철회를 정확히 반영하는 것 자체가 보안 요구사항이 된다.

2. 마이데이터 전송 보안의 전체 구조

마이데이터 전송 보안은 "누가 책임지는가(관리)", "누가 접근하는가(접근통제)", "무엇이 어떻게 오가는가(전송·저장 보호)", "멈추거나 터지면 어떻게 하는가(가용성·사고대응)"의 네 축으로 구성된다. 이 네 축은 독립적이지 않고 사슬처럼 엮여 있어, 가장 약한 고리의 강도가 전체 보안 수준을 결정한다.

flowchart LR
  subgraph Provider["정보제공자(전송자)"]
    DB1[(개인신용정보)]
    AUTH1["인증·접근통제"]
  end
  subgraph Channel["전송 구간"]
    TLS["mTLS 암호화 채널"]
    TOK["접근토큰(최소권한·단기)"]
  end
  subgraph MyData["마이데이터 사업자(수신자)"]
    AUTH2["인증·접근통제"]
    DB2[(수집 정보 저장·암호화)]
  end
  US["정보주체(전송요구)"] --> MyData
  DB1 --> AUTH1 --> TLS
  TOK --> TLS
  TLS --> AUTH2 --> DB2
  CPO["보호책임자(CPO)·정책·점검"] -.총괄.-> Provider
  CPO -.총괄.-> MyData

위 그림에서 보듯 전송은 정보주체의 전송요구를 기점으로, 제공자의 데이터베이스에서 인증·접근통제를 거쳐 암호화된 채널(mTLS) 로 수신자에게 전달되고, 수신자 측에서 다시 접근통제 아래 안전하게 저장된다. 그리고 이 흐름 전체를 양측의 보호책임자가 정책·점검으로 총괄한다. 안내서의 요구사항은 대부분 이 그림의 각 구간에 매핑된다 — 아래 3~5장은 각각 관리(CPO), 접근관리, 전송·저장·가용성을 다룬다.

이 구조에서 특히 중요한 것은 접근토큰이 채널과 분리되어 관리된다는 점이다. 전송요구에 따라 발급되는 토큰은 "어느 정보주체의, 어떤 범위의 정보를, 언제까지" 가져갈 수 있는지를 담은 열쇠이므로, 토큰의 발급·검증·폐기 전 과정이 전송 보안의 중심축이 된다. 채널(mTLS)이 "통로의 안전"을 보장한다면, 토큰은 "권한의 안전"을 보장하며, 둘은 상호 보완적이어서 어느 하나만으로는 전송을 신뢰할 수 없다.

3. 전송대상 개인정보 보호책임자(CPO) 지정

안전조치는 기술 이전에 "누가 책임지고 관리하는가"에서 출발한다. 아무리 정교한 기술 통제를 갖춰도 이를 총괄하고 주기적으로 점검하며 사고 시 지휘할 주체가 없으면, 통제는 설치된 채 방치되고 사고 대응은 표류한다. 그래서 안내서는 전송 업무를 관장하는 개인정보 보호책임자(CPO) 를 명확히 지정해 전송 보안 정책의 수립과 이행 점검, 침해사고 대응을 총괄하도록 요구한다.

CPO 체계가 실효를 가지려면 실질적 권한과 독립성이 핵심이다. 보호책임자가 현업(영업·서비스) 부서에 종속되면, "전송 속도를 높이자", "인증 단계를 줄이자" 같은 편의 요구에 밀려 보안 통제를 완화하려는 압력에 저항하기 어렵다. 따라서 CPO는 경영진에 직접 보고(직보)할 수 있는 위치에서, 예산·인력·조직권한을 배분받아야 한다. 이는 CISO·CPO의 독립성을 강조하는 ISMS-P·신용정보법의 취지와도 정합한다.

또한 전송은 양자 행위이므로 전송자와 수신자 양측 모두 책임 주체를 명확히 해야 한다. 한쪽만 책임 체계를 갖추면 사고 발생 시 "제공 단계의 문제인지 수신 단계의 문제인지" 책임 소재가 흐려지고 대응이 지연된다. 실무적으로는 양측 CPO가 전송 규격·보안 요구사항을 사전에 합의하고, 정기적으로 로그·점검 결과를 교차 확인하는 거버넌스를 둔다. 예컨대 특정 사업자에서 이상 전송이 탐지되면, 수신자 CPO의 판단만으로 끝내지 않고 제공자 CPO에게 통지해 공동 조사·차단하는 협력 절차를 사전에 문서화한다.

나아가 CPO의 역할은 사고 발생 이후의 "소방수"에 그치지 않는다. 신규 서비스 기획 단계에서 전송 범위·보관기간·이용 목적을 검토하고, 개인정보 영향평가(PIA)와 같은 사전 통제를 통해 위험을 설계 단계에서 걷어내는 것이 더 중요하다. 사고가 터진 뒤의 복구 비용과 신뢰 손실은, 설계 단계에서의 통제 비용과 비교할 수 없이 크기 때문이다. 이런 의미에서 CPO 지정은 조직에 보안을 "상시 묻는 질문"으로 심는 장치다.

항목 내용 이유
CPO 지정 전송 업무 총괄 보호책임자 지정·책임 명확화 통제의 운영·점검 주체 부재 방지
역할 전송 보안 정책 수립·이행 점검, 침해사고 대응 총괄 설치된 통제의 지속적 실효성 유지
독립성 실질 권한·독립성, 경영진 직보 체계 현업의 통제 완화 압력에 대한 저항력
양측 체계 전송자·수신자 모두 책임 주체 지정·협력 절차 사고 시 책임 소재 명확화·공동 대응

4. 전송대상 개인정보처리시스템 접근 관리

접근 관리의 원리는 "필요한 사람이, 필요한 만큼만, 흔적을 남기고" 로 요약된다. 전송 데이터는 결국 개인정보처리시스템에 저장·처리되므로, 이 시스템에 누가 어디까지 접근하는지를 통제하지 못하면 암호화·전송 보호가 무의미해진다.

flowchart LR
  A["접근권한 최소화·직무분리"] --> B["다요소 인증(MFA)"]
  B --> C["접속기록 보관·위변조 방지"]
  C --> D["이상행위 탐지·자동 차단"]
  D -.피드백.-> A

첫째, 최소권한과 직무분리다. 처리시스템 권한은 업무상 반드시 필요한 범위로 좁히고, 개발자와 운영자, 조회 권한과 변경 권한을 분리한다. 그 이유는 한 계정이 탈취되더라도 그 계정으로 도달 가능한 정보의 범위를 좁혀 피해를 국한하기 위함이다. 권한은 한 번 부여로 끝내지 않고 입·퇴사·직무변경에 맞춰 주기적으로 회수·재검토해야 하는데, 방치된 유휴 계정과 과다 권한이 실제 사고의 가장 흔한 진입점이기 때문이다.

둘째, 인증 강화다. 비밀번호 단일 인증은 피싱·재사용·무차별 대입에 취약하므로, 마이데이터 전송 맥락에서는 사람의 로그인에 다요소 인증(MFA) 을 적용하고, 기계 간 API 호출에는 상호 TLS 인증(mTLS)과 단기 접근토큰을 결합한다. 토큰은 탈취되더라도 피해를 최소화하도록 유효기간을 짧게, 권한 범위(scope)를 좁게 발급하는 것이 실무의 핵심이다.

셋째, 접속기록 관리와 이상행위 탐지다. 모든 접속·처리 행위를 접속기록으로 남기고 위변조 방지 조치(해시·무결성 보호·분리 보관)와 함께 보관한다. 접속기록은 사후 추적의 근거일 뿐 아니라, 심야 대량 조회나 평소 패턴을 크게 벗어난 전송 요청 같은 이상행위를 실시간 탐지하는 입력이 된다. 예컨대 한 계정이 평소의 수백 배에 달하는 전송 요청을 짧은 시간에 발생시키면 자동 차단·알림이 발동하도록 설계하고, 그 결과를 다시 권한 정책에 피드백해 통제를 강화한다.

이 세 통제는 서로를 보완한다. 최소권한이 "피해 범위"를 좁히고, MFA가 "침입 가능성"을 낮추며, 접속기록·이상탐지가 "탐지와 사후 추적"을 담당한다. 어느 하나가 뚫려도 나머지가 피해를 흡수하는 다층 방어(defense in depth) 구조로 설계해야, 단일 통제 실패가 곧바로 대량 유출로 이어지는 사태를 막을 수 있다.

항목 내용
접근권한 최소권한·직무분리, 권한 부여·회수의 주기적 검토
인증 MFA(사람)·mTLS·단기 토큰(기계), 세션·계정 관리
접속기록 접속·처리기록 보관 및 위변조 방지, 분리 보관
통제·탐지 접근통제 시스템, 이상행위 모니터링·자동 차단

5. 개인정보 관리 및 재해·재난 대비

전송 데이터의 안전은 이동 중(in transit)과 저장 중(at rest) 양쪽을 모두 지켜야 완성된다. 전송 구간은 TLS/mTLS로 암호화해 중간자 공격을 막고, 수신 후 저장되는 데이터는 암호화하여 저장매체 탈취나 내부자 유출 시에도 평문 노출을 방지한다. 어느 한쪽만 보호하면 — 예컨대 전송은 암호화하되 저장은 평문으로 두면 — 가장 취약한 지점이 전체 보안을 결정하게 된다.

여기에 데이터가 전달 과정에서 바뀌지 않았음을 보장하는 무결성 검증(전자서명·해시)과, 대량 유출 시도를 탐지·차단하는 DLP 성격의 통제를 둔다. 특히 마이데이터에서는 "잘못된 사람에게 전송되는" 오전송도 치명적이므로, 수신자 식별·인가를 전송 직전에 재확인하는 통제가 중요하다.

한편 마이데이터는 다수 기관이 실시간으로 연결된 서비스라 가용성 자체가 보안 요구사항이 된다. 특정 제공자의 시스템이 재해로 멈추면 그 기관 정보에 의존하는 전송 체인 전체가 영향을 받기 때문이다. 따라서 백업·복구 체계(BCP/DRS)와 시스템 이중화로 서비스 연속성을 확보하고, 침해사고 발생 시 신속한 격리·조사·통지·신고 절차를 사전에 마련해 둔다. 금융 분야에서는 침해사고를 인지하면 감독기관에 지체 없이 보고해야 하므로, 기술적 복구와 더불어 규제 보고 절차를 대응 매뉴얼에 포함해야 한다.

가용성 보호에는 재해뿐 아니라 대량 트래픽·장애 전파에 대한 대비도 포함된다. 전송요구가 특정 시점(월초·급여일 등)에 몰리면 제공자 API에 부하가 집중되는데, 이때 처리 지연이 재시도 폭주로 이어져 장애가 번지는 "장애 전파" 위험이 있다. 이를 막기 위해 호출 속도 제한(rate limit), 큐잉, 지수 백오프 재시도 같은 부하 제어 설계를 두어, 한 기관의 과부하가 생태계 전체의 가용성을 끌어내리지 않도록 한다. 즉 가용성은 하드웨어 이중화만이 아니라 트래픽 관리까지 포함하는 종합 설계의 산물이다.

항목 내용
암호화 전송구간(TLS/mTLS)·저장 데이터 암호화
무결성·유출방지 전송 데이터 위변조 방지(서명·해시), 유출 탐지·차단(DLP)
오전송 방지 수신자 식별·인가 재확인, 전송 대상·범위 검증
재해·재난 대비 백업·복구(BCP/DRS), 이중화로 연속성 확보
사고 대응 침해사고 격리·조사·통지·규제 보고 절차 수립

6. 전송자·수신자 책임 비교와 적용 사례

전송자와 수신자는 같은 안전조치 목표를 공유하지만, 위험의 무게 중심이 다르다. 전송자(정보제공자)는 "정당한 요구에만, 정확한 범위로, 올바른 수신자에게" 내보내는 것이 핵심이라 전송요구의 진위 확인·수신자 인증·전송 범위 최소화에 무게가 실린다. 반대로 수신자(마이데이터 사업자)는 받은 대량 정보를 "안전하게 보관하고 목적 내에서만 쓰는" 것이 핵심이라 저장 암호화·접근통제·목적 외 이용 방지에 무게가 실린다. 이 차이를 이해하지 못하고 양쪽에 똑같은 체크리스트만 기계적으로 적용하면, 각자에게 정작 중요한 위험을 놓치게 된다.

구분 전송자(정보제공자) 수신자(마이데이터 사업자)
위험 중심 오전송·과다전송·요구 위변조 저장 정보 유출·목적 외 이용
핵심 통제 전송요구 검증·수신자 인증·범위 최소화 저장 암호화·접근통제·이용 통제
대표 사고 타인에게 전송, 요청보다 넓은 전송 수집 정보 대량 유출, 재판매

구체 사례로, ① 한 사업자의 서버 설정 오류로 접근토큰 검증이 느슨해져 타 사용자의 자산 정보가 조회된 사례는 수신자 측 접근통제·토큰 관리의 중요성을 보여준다. ② 제공자 API가 요청 범위(예: 최근 1년)보다 넓은 전 기간 데이터를 반환한 과다전송 사례는 전송자 측 범위 검증의 필요성을 보여준다. ③ 수백 개 참여 기관 중 보안이 취약한 소규모 사업자가 생태계 전체의 공격 표면이 되는 "약한 고리" 문제는, 표준 API의 보안적합성 심사를 통과한 기관만 참여시키는 인증·감독 체계의 당위성을 보여준다.

이 사례들의 공통 교훈은, 전송 보안이 단일 기술의 문제가 아니라 요구 검증→전송→저장→이용의 전 생애주기에 걸친 통제 설계의 문제라는 점이다. 어느 사업자가 "우리는 전송 구간을 TLS로 암호화한다"고 주장해도, 토큰 검증이 허술하거나 저장 정보가 평문이면 공격자는 가장 약한 지점을 노린다. 따라서 점검도 단일 항목이 아니라 전 구간을 꿰는 시나리오 기반 점검(실제 공격 경로를 가정한 모의 전송·침투 시험)으로 수행해야 실효를 가진다.

7. 심화 — 표준·제도 연계와 최신 동향

마이데이터 전송 보안은 단독 안내서로 완결되지 않고, 여러 제도·표준과 맞물려 작동한다. 첫째, 표준 API와의 정합이다. 사업자는 기능적합성·보안적합성 심사를 통과한 표준 API를 사용해야 하며, 본 안내서의 안전조치는 그 API 위에서의 운영 보안을 규정한다. 둘째, mTLS와 토큰 보안이다. 기관 간 신뢰는 상호인증(mTLS)으로 확보하고, OAuth 기반 접근토큰은 최소 권한·단기 유효·범위 제한으로 설계해 탈취 시 피해를 최소화한다.

셋째, 개인정보 전송요구권의 전(全)분야 확대다. 금융 마이데이터로 시작된 전송요구권은 개인정보보호법 개정을 통해 공공·의료 등으로 확장되는 흐름에 있어, 전송 보안 요구는 금융을 넘어 전 산업의 공통 과제가 되고 있다(세부 시행 시기·범위는 제도 진행 상황에 따라 달라질 수 있어 단정은 피한다). 넷째, 제로트러스트와의 접목이다. "한 번 인증했으니 신뢰한다"가 아니라 매 전송·매 접근을 검증하는 제로트러스트 원칙은, 기관 경계를 상시 넘나드는 마이데이터 전송과 특히 잘 맞는다. 향후 전송 보안은 정적 체크리스트에서 지속 검증·행위 기반 탐지 중심으로 진화할 것으로 전망된다.

이 흐름에서 주목할 변화는, 전송 대상 정보가 점차 비정형·대용량·실시간으로 넓어진다는 점이다. 단순 잔액·거래내역을 넘어 결제 패턴, 행동 데이터, 나아가 의료·건강 정보까지 포함되면 민감도가 높아지고, AI 기반 분석과 결합될 때 재식별·프로파일링 위험이 커진다. 따라서 전송 보안은 암호화·접근통제 같은 전통적 통제에 더해, 전송된 정보가 어떻게 결합·활용되는지까지 보는 이용 단계의 통제로 범위를 넓혀야 한다. 가명·익명처리, 목적 외 이용 차단, 결합 이력 관리가 그 구체적 수단이다.

8. 고려사항 및 시사점(기술사 관점)

  • 전송 전 구간의 신뢰 사슬: 인증·암호화·접근통제·저장보호 중 어느 하나가 약하면 전체가 무너진다. mTLS 기반 상호인증과 단기·최소권한 토큰을 결합해 end-to-end 신뢰를 설계하고, "가장 약한 고리"를 주기적으로 식별·보강하는 것이 핵심이다.
  • 표준과 운영 보안의 병행 충족: 표준 API(기능·보안적합성)와 본 안내서의 안전조치는 둘 다 충족해야 하는 별개 요건이다. 적합성 심사 통과가 운영 중 보안을 보장하지 않으므로, 상시 점검·로그 분석으로 운영 보안을 지속 검증해야 한다.
  • 법·제도 정합과 관리적 통제의 실효성: 신용정보법·개인정보보호법의 안전성 확보조치 기준과 정합하되, 문서화에 그치지 않도록 정기 점검·임직원 교육·모의훈련으로 관리적 통제의 실효성을 유지한다.
  • 생태계 신뢰가 곧 경쟁력: 참여 기관 전체가 동일 수준의 보안을 지켜야 하므로, 취약한 참여자를 걸러내는 인증·감독 체계와 상호 책임 거버넌스가 마이데이터 확산의 전제다. 보안 수준은 비용이 아니라 신뢰 기반의 사업 경쟁력으로 보아야 한다.
  • 프라이버시 바이 디자인: 전송 범위 최소화·목적 구속·보관기간 제한을 설계 단계부터 내재화해, 사후 통제가 아니라 구조적으로 위험을 줄이는 접근이 바람직하다.
  • 가용성과 보안의 균형: 보안을 강화하다 전송이 지연·중단되면 그 자체가 가용성 사고가 된다. 부하 제어·이중화와 보안 통제를 함께 설계해, 안전성과 서비스 연속성 사이의 트레이드오프를 공학적으로 관리해야 한다.

참고자료

  • 개인정보보호위원회·금융위원회, 마이데이터(본인신용정보관리업) 관련 안내 자료, https://www.pipc.go.kr
  • 금융보안원, 마이데이터 기술 가이드라인·표준 API 규격, https://www.fsec.or.kr
  • 신용정보의 이용 및 보호에 관한 법률(신용정보법), https://www.law.go.kr

한 줄 요약: 마이데이터 전송 보안 안내서는 보호책임자(CPO) 지정, 처리시스템 접근관리(최소권한·MFA·접속기록·이상탐지), 전송·저장 보호와 재해대비(암호화·무결성·백업·사고대응) 를 전송자·수신자 양측에 공통 요구하여, 기관 간 상시 오가는 민감정보의 end-to-end 신뢰 사슬을 확보하도록 한다.