중요데이터 관리와 비식별화

보안이 활용을 막지 않는 설계

중요데이터 5등급 체계의 설계 근거, 개인정보 별도 관리 원칙, 비식별화 기법별 설계 패턴, 시나리오별 비식별화 전략, 접근 통제와 SQL 로깅, ISMS 인증 대응까지를 다룬다.

Data Governance
저자

Kwangmin Kim

공개

2026년 03월 27일

1 정의

정의: 중요데이터 관리 (Sensitive Data Management)

중요데이터 관리는 조직이 보유한 데이터를 민감도에 따라 등급화하고, 등급별 접근 통제, 비식별화, 저장 요건, 감사 로깅 정책을 체계적으로 적용하는 활동이다.

  • 범위: 데이터 등급 분류 \(\rightarrow\) 개인정보 식별 \(\rightarrow\) 비식별화 규칙 설계 \(\rightarrow\) 접근 통제 \(\rightarrow\) 감사 추적
  • 목적: 법적 규제 준수와 데이터 활용 가능성의 균형 확보
  • 참조: DAMA-DMBOK2 Chapter 7 (Data Security), ISO/IEC 27001, 개인정보보호법, GDPR

Part 04에서 다룬 공통코드와 마스터 데이터가 “데이터의 의미”를 관리하는 것이었다면, 이번 Part 05는 “데이터의 민감도”를 관리하는 것이다.

2 개념 및 원리

2.1 거버넌스 프레임워크 내 위치

중요데이터 관리는 데이터 보안(Data Security) 영역에 속하며, 데이터 거버넌스의 실행 계층에서 메타데이터 관리, 데이터 품질 관리와 나란히 작동한다. 메타데이터 관리가 “이 칼럼이 무엇인가”를 정의한다면, 중요데이터 관리는 “이 칼럼이 얼마나 민감한가”를 정의한다. 데이터 품질 관리가 값의 정확성을 다룬다면, 중요데이터 관리는 값의 노출 범위를 다룬다.

2.2 구성 요소 분해

중요데이터 관리 체계는 네 가지 구성 요소로 분해된다.

구성 요소 역할 산출물
등급 분류 데이터의 민감도를 정량적으로 구분한다 5등급 분류표, 칼럼별 등급 목록
비식별화 규칙 민감 데이터를 활용 가능한 형태로 변환하는 기준을 명문화한다 마스킹 규칙 정의서, 기법 선택 가이드
접근 통제 누가 어떤 데이터에 접근할 수 있는지를 제어한다 권한 매트릭스, 승인 프로세스
감사 추적 접근 이력을 기록하고 이상 패턴을 탐지한다 조회 로그, 감사 리포트

이 네 가지는 독립적인 기능이 아니라, 분류 \(\rightarrow\) 규칙 정의 \(\rightarrow\) 통제 적용 \(\rightarrow\) 이력 추적이라는 순차적 파이프라인으로 연결된다. 하나라도 빠지면 체계 전체가 작동하지 않는다.

2.3 5등급 체계의 설계 근거

5등급 체계는 임의적으로 5개를 고른 것이 아니다. 보안 정책에서 필요한 처리의 차별화 단계가 약 4~6개 수준이고, 5개가 가장 균형 잡힌 분류라는 경험적 기준이 있다. 3등급은 너무 거칠어서 “내부용”과 “대외비”의 차이를 표현하지 못하고, 7등급 이상은 등급 간 경계가 모호해져 분류자마다 다르게 판단하게 된다.

비유하자면, 도로에 속도 제한 표지판만 세워 놓고 단속을 하지 않는 것과 같다. 60km/h 제한 구간이라는 분류가 있어도, 실제로 속도위반 시 과태료가 부과되지 않으면 아무도 지키지 않는다. 등급이 통제와 연결되지 않으면 같은 현상이 발생한다.

등급 설계에서 중요한 것은 각 등급의 경계를 예시로 명확히 하는 것이다. “1등급은 극비”라고만 써두면 담당자마다 다른 기준으로 등급을 부여한다. 예시를 포함해야 한다.

등급 명칭 정의 예시 접근 통제 저장 요건
1등급 극비 외부 유출 시 조직에 치명적 손해를 주는 데이터 미발표 재무 결과, 인수합병 계획, 핵심 영업 기밀 임원급 이상, 전 접근 로깅 암호화 저장 필수
2등급 대외비 임직원 공유 가능하나 외부 공개 불가 직원 급여 정보, 고객 계약 조건, 영업 파이프라인 부서 단위 접근 통제 외부 발송 시 암호화 전송 필수
3등급 내부용 내부 업무 목적으로만 사용하는 데이터 고객 연락처, 주문 이력, 직원 인사 정보 업무 관련 직원만 접근, 접근 로그 기록 일반 저장
4등급 제한 접근 제한이 있으나 비교적 넓게 공유 가능 집계된 고객 통계, 부서별 실적 요약 사내 전 직원 접근 가능, 외부 공개 불가 일반 저장
5등급 공개 외부 공개 가능 공개 제품 카탈로그, 공식 발표 자료, 공개 API 데이터 제한 없음 일반 저장

이 표에서 핵심은 등급 칼럼이 아니라 접근 통제와 저장 요건 칼럼이다. 등급이 통제 정책과 직접 연결되어야 등급 분류에 의미가 생긴다.

2.4 개인정보(PI)는 별도 관리

개인정보는 5등급 체계와 별도로 관리해야 한다. 이유는 법적 규제(개인정보보호법, GDPR, CCPA 등)가 등급 분류와 무관하게 별도의 처리 기준을 강제하기 때문이다.

법적으로 개인정보는 수집 목적, 보존 기간, 제3자 제공 여부, 파기 방법을 명시해야 한다. 이것은 1~5등급 체계로 표현할 수 없다. 예를 들어, 3등급(내부용) 데이터라도 개인정보에 해당하면 보존 기간이 지나면 반드시 파기해야 한다. 반대로, 1등급(극비) 데이터라도 개인정보가 아니면 파기 의무는 없다. 두 축이 독립적으로 작동하는 것이다.

개인정보의 유형도 구분해서 관리하는 것이 좋다.

유형 정의 예시 비식별화 강도
직접 식별 정보 개인을 직접 식별하는 정보 성명, 주민등록번호, 여권번호 삭제 또는 가명화
간접 식별 정보 단독으로는 식별 어렵지만 조합 시 식별 가능 주소, 전화번호, 이메일 마스킹 또는 일반화
연관 정보 특정 개인과 연결될 수 있는 정보 구매 이력, 행동 로그 잡음 추가 또는 집계화

이 유형 분류가 있어야 비식별화 규칙을 유형별로 차등 적용할 수 있다. 직접 식별 정보는 원본을 절대 노출하지 않고, 간접 식별 정보는 분석 목적에 따라 마스킹 수준을 조절하고, 연관 정보는 집계 수준에서 제공하는 식이다.

2.5 등급 부여의 실무 프로세스

등급은 데이터 오너(Data Owner)가 부여하고, 보안 관리자가 검토한다. 초기 등급 부여 시에는 칼럼 단위가 아닌 테이블 단위로 대표 등급을 부여하고, 이후 칼럼별 세분화를 진행하는 것이 현실적이다. 모든 칼럼을 한꺼번에 분류하려 하면 작업량이 폭증하여 프로젝트가 정체된다. 테이블 대표 등급으로 빠르게 전체 커버리지를 확보한 뒤, 민감도가 높은 테이블부터 칼럼 단위로 세분화하는 접근이 실무적으로 효과적이다.

등급 부여 후에는 정기 검토(예: 반기 1회)를 통해 등급의 적절성을 재평가한다. 사업 환경 변화, 신규 규제 도입, 데이터 활용 목적 변경에 따라 등급이 상향 또는 하향 조정될 수 있다.

2.6 비식별화 기법의 원리

등급 체계가 “어떤 데이터가 민감한가”를 정의했다면, 비식별화는 “민감한 데이터를 어떻게 처리하여 활용 가능하게 만드는가”를 정의한다.

비식별화를 “케이스바이케이스로 담당자가 판단”하면 두 가지 문제가 생긴다. 일관성 없는 처리와 책임의 불명확함이다. 같은 전화번호 칼럼을 A 담당자는 뒷 4자리 마스킹으로, B 담당자는 전체 삭제로 처리하면 분석 결과의 신뢰성이 깨진다. 문제가 발생했을 때 “왜 이렇게 처리했는가”에 대한 답이 “담당자가 그때 그렇게 판단했다”이면 책임 소재가 불분명하다.

규칙이 명문화되고 시스템에 등록되면 처리는 시스템이 하고 사람은 규칙의 설계와 검토만 담당한다. 처리의 일관성이 보장되고, 규칙을 승인한 사람이 책임 주체가 명확해진다.

마스킹(Masking): 데이터의 일부를 *나 X로 대체한다. 전화번호 010-1234-5678을 010-****-5678로 표현한다. 원본 값의 형식을 유지하면서 일부 정보를 가린다.

마스킹 방식 설명 예시
고정 위치 특정 위치의 문자를 대체 앞 3자리 제외 전부: 010-****-****
패턴 기반 데이터 구조에 따라 대체 규칙 적용 이메일 @ 앞 절반: kwa***@example.com

일반화(Generalization): 구체적인 값을 더 넓은 범주로 대체한다.

원본 일반화 결과 일반화 수준
생년월일 1985-03-15 1980년대생 10년 단위
주소 서울시 강남구 역삼동 123번지 서울시 강남구 구 단위
나이 34세 30~39세 10세 구간

일반화는 데이터의 통계적 분석 가능성을 일부 유지하면서 식별 가능성을 낮춘다. 연령대별 구매 패턴 분석처럼 개별 나이가 아닌 구간 정보로 충분한 분석에 적합하다.

삭제(Suppression): 데이터를 NULL 또는 고정 값으로 대체한다. 가장 강력한 비식별화 방법이지만 해당 데이터를 분석에 사용할 수 없다. 주민등록번호처럼 어떤 형태로도 제공해서는 안 되는 데이터에 적용한다. NULL로 대체하면 COUNT(*) vs COUNT(column) 결과가 달라지고, NOT NULL 제약 조건이 있는 칼럼에는 적용할 수 없다. 고정 값(예: 'REDACTED')으로 대체하는 것이 실무에서 더 안전하다.

가명화(Pseudonymization): 원본 값을 일관된 가짜 값으로 대체한다. 홍길동은 항상 박민수로, 010-1234-5678은 항상 010-9876-5432로 변환된다. 일관성이 핵심이다. 같은 원본 값이 다른 가명으로 변환되면 JOIN이 깨진다. 가명화 매핑 테이블 자체가 가장 민감한 데이터가 된다. 이 테이블에 접근할 수 있으면 가명화를 역변환할 수 있기 때문이다. 매핑 테이블은 1등급(극비)으로 분류하고, 접근 권한을 최소한으로 제한해야 한다.

잡음 추가(Noise Addition): 숫자 데이터에 임의의 오차를 더한다. 실제 구매 금액에 \(\pm 5\%\) 범위의 랜덤 오차를 추가한다. 개별 레코드의 정확성은 떨어지지만 집계 통계는 대체로 유사하게 유지된다. 잡음 추가가 유효한 조건은 분석 목적이 집계(평균, 합계, 분포)일 때이다. 개별 레코드의 정확한 값이 필요한 분석(이상치 탐지, 개별 고객 프로파일링 등)에는 적합하지 않다.

2.7 기법 선택 가이드

비식별화 기법은 분석 목적과 데이터 민감도의 교차점에서 결정한다.

분석 목적 낮은 민감도 (4등급) 중간 민감도 (3등급) 높은 민감도 (1~2등급)
집계 통계 원본 제공 잡음 추가 일반화 + 잡음 추가
패턴 분석 원본 제공 마스킹 가명화
개별 추적 불필요 원본 제공 일반화 삭제
테스트 데이터 원본 제공 가명화 가명화 + 삭제(PI)

3 왜 필요한가

3.1 보안 때문에 데이터를 못 쓴다는 말의 진짜 의미

분석팀이 “고객 데이터를 분석하고 싶은데 개인정보라서 못 받는다”고 할 때, 그 말의 진짜 의미는 두 가지 중 하나이다. 첫 번째는 실제로 법적으로 제공이 불가능한 경우이다. 두 번째는 제공 방법을 모르거나, 제공 기준이 없거나, 제공 프로세스가 없어서 아무도 책임을 지지 않으려는 경우이다.

현실에서 두 번째 경우가 훨씬 많다. “개인정보니까 안 된다”가 실질적으로는 “비식별화 기준이 없어서 어떻게 처리해야 할지 모른다”이거나 “문제 생기면 책임질 사람이 없어서 아무도 결정을 안 한다”인 것이다.

3.2 부재 시 구체적 비용과 리스크

중요데이터 관리 체계가 없을 때 발생하는 비용은 추상적이지 않다.

리스크 유형 구체적 시나리오 예상 비용
법적 제재 개인정보 유출 사고 시 개인정보보호법 위반 과징금 매출액의 3% 이하 또는 전체 매출의 4% (GDPR)
활용 지연 비식별화 기준 부재로 데이터 제공 요청이 수 주간 정체 분석 프로젝트 지연, 의사결정 기회 비용
일관성 붕괴 담당자별 다른 마스킹 기준 적용 분석 결과 신뢰도 하락, 재작업 비용
감사 실패 접근 이력 미기록으로 ISMS 인증 심사 부적합 판정 인증 취소, 거래처 계약 해지
보안 사고 퇴직자 계정의 권한이 회수되지 않아 민감 데이터 유출 평판 손실, 소송 비용

3.3 규제 준수 관점

중요데이터 관리 체계를 제대로 설계하면 규제 준수가 시스템적으로 보장된다. 어떤 데이터가 중요데이터인지를 명확히 분류하고, 각 분류에 따른 처리 기준을 명문화하고, 시스템이 그 기준을 자동으로 적용하면 “어떻게 처리해야 하나”를 매번 논의할 필요가 없다. 기준에 따른 결과물(비식별화된 데이터)을 제공하고, 제공 이력을 남기면 책임 소재도 명확해진다.

개인정보보호법, GDPR, CCPA는 공통적으로 다음을 요구한다.

규제 요구사항 시스템 대응
보유 데이터 현황 파악 TB_SENSITIVE_COLUMN의 등급 분류 + is_personal_info 플래그
처리 목적 명시 비식별화 규칙(TB_MASK_RULE)에 목적별 규칙 정의
최소 수집 원칙 접근 통제(TB_VIEW_PERMISSION)로 필요 최소 범위만 허용
보존 기간 준수 등급 메타데이터에 보존 기간 속성 추가, 자동 파기 트리거
파기 의무 이행 조회 로그(TB_VIEW_LOG)로 파기 이행 증빙

이 대응 구조가 있으면 규제 당국의 자료 요청이나 정기 감사에도 시스템 조회만으로 즉시 응답할 수 있다.

4 응용 분야

분야 거버넌스 활동 구체적 예시
금융 고객 신용정보 등급 관리 신용정보법에 따른 개인신용정보 5단계 분류, Basel III 규제 보고 시 데이터 마스킹
의료 환자 정보 비식별화 HIPAA 준수를 위한 Safe Harbor 기법 적용, 임상시험 데이터의 가명화
제조 영업 기밀 등급 관리 제조 공정 데이터의 극비 분류, 협력사 제공 시 일반화 처리
공공 공공데이터 개방 전 비식별화 통계 목적 데이터의 k-익명성 검증, 공공데이터 포털 제공 시 삭제 처리
유통 고객 행동 데이터 관리 구매 이력의 집계화 처리, 마케팅 분석용 가명화 데이터셋 생성
IT/플랫폼 사용자 로그 비식별화 IP 주소 마스킹, 접속 로그의 잡음 추가, GDPR 삭제 요청(Right to Erasure) 대응

분야마다 적용하는 비식별화 기법의 조합이 다르다. 금융은 규제 보고 정확성이 중요하므로 마스킹과 접근 통제에 집중하고, 의료는 연구 목적의 데이터 재활용이 필수적이므로 가명화와 k-익명성 검증이 핵심이 된다. 제조는 영업 기밀 보호가 우선이므로 등급 분류와 삭제 처리의 비중이 높고, 공공은 개방과 보호의 균형이 쟁점이므로 일반화와 집계화가 주요 기법이다. 이처럼 동일한 5등급 체계와 비식별화 규칙이라도 분야별 규제 환경과 데이터 활용 목적에 따라 운영 방식이 달라진다.

5 예시

5.1 Before: 비식별화 기준 없이 운영

분석팀이 고객 주문 데이터를 요청한다. 보안팀은 “개인정보가 포함되어 있으니 안 된다”고 거부한다. 분석팀은 우회 경로를 찾아 운영 DB에 직접 접속하거나, 이메일로 엑셀 파일을 주고받는다. 누가 어떤 데이터를 가져갔는지 추적할 수 없다.

항목 Before
데이터 요청 처리 기간 2~4주 (담당자 간 협의)
마스킹 기준 담당자 재량 (비일관적)
접근 이력 미기록
ISMS 심사 대응 수동 문서화 (수 주 소요)
퇴직자 권한 관리 수동 회수 (누락 빈번)

5.2 After: 5등급 체계 + 비식별화 규칙 + 접근 통제 적용

분석팀이 메타데이터 시스템에서 데이터를 조회한다. 시스템이 자동으로 등급에 따른 마스킹을 적용한다. 원본이 필요하면 승인 프로세스를 통해 권한을 부여받는다. 모든 조회 이력이 자동 기록된다.

항목 After
데이터 요청 처리 기간 즉시 (마스킹 적용 데이터) 또는 1~2일 (원본 권한 승인)
마스킹 기준 시스템 등록 규칙에 따라 자동 적용
접근 이력 전수 자동 로깅
ISMS 심사 대응 시스템 조회로 실시간 증빙 (수 일)
퇴직자 권한 관리 만료일 자동 비활성화

핵심적인 변화는 “사람이 매번 판단”에서 “시스템이 규칙에 따라 자동 처리”로 전환되는 것이다. 사람은 규칙의 설계와 예외 승인만 담당하고, 반복적인 마스킹 적용과 이력 기록은 시스템이 수행한다. 이로써 보안팀은 “안 된다”가 아니라 “이 조건으로 제공한다”고 답할 수 있게 된다.

6 코드/도구 예시

6.1 중요데이터 등급 관리 테이블

CREATE TABLE TB_SENSITIVE_COLUMN (
    table_id          VARCHAR(100) NOT NULL,
    column_id         VARCHAR(100) NOT NULL,
    sensitivity_level INT          NOT NULL CHECK (sensitivity_level BETWEEN 1 AND 5),
    is_personal_info  CHAR(1)      DEFAULT 'N' CHECK (is_personal_info IN ('Y', 'N')),
    pi_type           VARCHAR(20),  -- DIRECT, INDIRECT, ASSOCIATED
    mask_rule_id      VARCHAR(50),
    classified_by     VARCHAR(50)  NOT NULL,
    classified_dt     DATE         NOT NULL,
    review_by         VARCHAR(50),
    review_dt         DATE,
    PRIMARY KEY (table_id, column_id)
);

sensitivity_level은 1~5 등급, is_personal_info는 개인정보 여부를 별도로 관리한다. 이 두 축이 분리되어야 하는 이유는 앞서 설명한 바와 같다. 등급은 조직 내 민감도를 반영하고, 개인정보 여부는 법적 처리 의무를 결정한다.

6.2 마스킹 규칙 정의 및 함수

-- 마스킹 규칙 정의 테이블
CREATE TABLE TB_MASK_RULE (
    mask_rule_id    VARCHAR(50)  NOT NULL PRIMARY KEY,
    rule_name       VARCHAR(100) NOT NULL,
    mask_type       VARCHAR(20)  NOT NULL,  -- FIXED_POS, PATTERN, FULL
    mask_pattern    VARCHAR(200),
    mask_char       CHAR(1)      DEFAULT '*',
    description     VARCHAR(500),
    created_by      VARCHAR(50)  NOT NULL,
    created_dt      DATE         NOT NULL
);

-- PostgreSQL 마스킹 함수 예시
CREATE OR REPLACE FUNCTION fn_mask_phone(p_phone VARCHAR)
RETURNS VARCHAR AS $$
BEGIN
    RETURN regexp_replace(p_phone, '(\d{3})-(\d{4})-(\d{4})', '\1-****-\3');
END;
$$ LANGUAGE plpgsql;

6.3 가명화 매핑 테이블

CREATE TABLE TB_PSEUDONYM_MAP (
    map_id          SERIAL       PRIMARY KEY,
    source_table    VARCHAR(100) NOT NULL,
    source_column   VARCHAR(100) NOT NULL,
    original_hash   VARCHAR(128) NOT NULL,  -- 원본의 해시값 (원본 자체는 저장하지 않음)
    pseudonym_value VARCHAR(200) NOT NULL,
    created_dt      DATE         NOT NULL,
    UNIQUE (source_table, source_column, original_hash)
);

6.4 시나리오: 분석팀의 실시간 데이터 조회

분석가가 메타데이터 시스템의 데이터 조회 기능을 통해 고객 주문 데이터를 조회한다. 중요데이터로 등록된 칼럼(이름, 전화번호, 이메일)은 조회 결과에서 마스킹 처리된다. 분석가가 원본 데이터 접근 권한을 별도로 부여받은 경우에만 원본이 보인다.

처리 흐름은 다음과 같다.

  1. 분석가가 조회 요청을 실행한다
  2. 데이터 조회 서비스가 쿼리 결과를 반환하기 전에 결과 셋의 각 칼럼이 중요데이터인지 확인한다(TB_SENSITIVE_COLUMN)
  3. 중요데이터이고 현재 사용자가 원본 접근 권한이 없으면 해당 칼럼의 값에 마스킹 규칙을 적용한다
  4. 조회 이력은 TB_VIEW_LOG에 기록한다
-- 마스킹 적용 조회 (의사 코드)
SELECT
    order_id,
    CASE
        WHEN has_permission(current_user, 'CUSTOMER', 'name', 'ORIGINAL')
        THEN c.name
        ELSE fn_mask_name(c.name)
    END AS customer_name,
    CASE
        WHEN has_permission(current_user, 'CUSTOMER', 'phone', 'ORIGINAL')
        THEN c.phone
        ELSE fn_mask_phone(c.phone)
    END AS phone,
    o.order_amount,
    o.order_dt
FROM orders o
JOIN customer c ON o.customer_id = c.customer_id
WHERE o.order_dt >= '2026-01-01';

6.5 시나리오: 개발/테스트 환경용 데이터 제공

운영 데이터를 복사해서 개발 환경에 제공해야 할 때 개인정보를 완전히 비식별화해야 한다. 이 경우 실시간 마스킹으로는 부족하다. 데이터 전체를 비식별화한 새 데이터셋을 생성해야 한다.

처리 흐름은 다음과 같다.

  1. 비식별화 배치 프로세스가 원천 테이블을 읽는다
  2. 각 칼럼의 비식별화 규칙(TB_MASK_RULE)을 적용한 후 대상 테이블에 쓴다
  3. 개인정보 칼럼은 가명화 또는 삭제 처리한다
  4. PK와 FK 관계를 유지한다

PK-FK 관계 유지가 핵심이다. 고객 ID가 가명화되면 주문 테이블의 고객 ID도 동일한 가명으로 변환되어야 JOIN이 가능하다. 가명화 매핑 테이블(TB_PSEUDONYM_MAP)이 이 일관성을 보장한다. 매핑 테이블 없이 매번 새로운 랜덤 값을 생성하면 테이블 간 참조 무결성이 깨진다.

6.6 접근 권한 관리 테이블

CREATE TABLE TB_VIEW_PERMISSION (
    perm_id         SERIAL       PRIMARY KEY,
    user_id         VARCHAR(50)  NOT NULL,
    table_id        VARCHAR(100) NOT NULL,
    column_id       VARCHAR(100),          -- NULL이면 테이블 전체
    access_level    VARCHAR(20)  NOT NULL,  -- ORIGINAL, MASKED, DENIED
    approved_by     VARCHAR(50)  NOT NULL,
    approved_dt     DATE         NOT NULL,
    expire_dt       DATE         NOT NULL,
    is_active       CHAR(1)      DEFAULT 'Y'
);

데이터 조회 권한은 테이블 단위, 환경 단위, 사용자 단위로 관리한다. 권한 부여는 승인 프로세스를 거쳐야 한다.

권한 신청 -> 데이터 오너 확인 -> 보안 관리자 승인 -> 권한 부여 -> 만료일 설정

만료일을 두는 이유는 업무 변경이나 퇴직 후에도 권한이 남아있는 “권한 좀비” 문제를 방지하기 위해서이다. 권한 만료가 가까워지면(예: 만료 7일 전) 사용자에게 갱신 또는 반납 안내를 보내야 한다. 갱신하지 않으면 자동으로 is_active = 'N'으로 전환된다.

6.7 SQL 로깅과 감사

CREATE TABLE TB_VIEW_LOG (
    log_id        SERIAL       PRIMARY KEY,
    user_id       VARCHAR(50)  NOT NULL,
    table_id      VARCHAR(100) NOT NULL,
    executed_sql  TEXT,
    row_count     INT,
    was_masked    CHAR(1)      DEFAULT 'Y',
    log_dt        TIMESTAMP    DEFAULT CURRENT_TIMESTAMP
);

로그에 포함되어야 하는 항목은 다음과 같다.

항목 칼럼명 설명
누가 user_id 조회 실행자
언제 log_dt 조회 일시
어떤 테이블을 table_id 대상 테이블
어떤 조건으로 executed_sql 실행된 SQL 전문
몇 건을 row_count 조회 결과 건수
마스킹 적용 여부 was_masked 마스킹이 적용되었는지

로그 데이터 자체도 중요데이터이다. 누가 언제 어떤 데이터를 조회했는지 로그가 유출되면 접근 패턴 분석을 통해 민감 정보를 간접적으로 유추할 수 있다. 예를 들어, 특정 사용자가 매일 같은 시간에 특정 고객의 주문 데이터를 조회한다면, 그 고객과 해당 사용자 사이에 특별한 관계가 있다는 것을 추론할 수 있다. 로그 테이블에 대한 접근은 보안 관리자와 감사팀으로 제한해야 한다.

6.8 ISMS 인증 대응

앞에서 설계한 등급 체계, 비식별화 규칙, 접근 통제, 로깅이 결합되면 ISMS 인증 심사의 데이터 관련 통제 항목 대부분을 시스템으로 증빙할 수 있다.

ISMS 통제 항목 요구사항 시스템 대응 증빙 방법
중요정보 식별 및 분류 자산 식별, 등급 분류 TB_SENSITIVE_COLUMN 등급 관리 칼럼별 등급 목록 조회
접근권한 관리 최소 권한 원칙, 승인 이력 TB_VIEW_PERMISSION 승인 이력 권한 부여/만료 이력 조회
접근 로그 관리 접근 기록 보관, 이상 탐지 TB_VIEW_LOG SQL 로깅 기간별 로그 조회, 이상 패턴 리포트
개인정보 처리 현황 PI 보유 현황 파악 is_personal_info = 'Y' 칼럼 목록 PI 칼럼 목록 + 데이터 주체 수
개인정보 비식별화 비식별화 기준, 적용 여부 TB_MASK_RULE 규칙 정의 규칙 목록 + 적용 결과 샘플
DB 접근 이력 관리 변경/조회 이력 보관 변경 이력 테이블 + 실행 로그 이력 테이블 조회

이 대응 관계가 명확하면 ISMS 심사 시 “이 통제 항목은 이 시스템의 이 화면에서 확인할 수 있다”고 직접 보여줄 수 있다. 엑셀 파일과 수동 관리 문서 대신 실시간 데이터로 증빙한다. 심사 준비 기간이 수 주에서 수 일로 단축되는 것이 실무적 임팩트이다.

7 관련 주제

카테고리 내 연결

다른 카테고리 연결

Subscribe

Enjoy this blog? Get notified of new posts by email: