본문 바로가기
개인정보 (Privacy)

개인정보 및 중요정보 기반 DBMS 자산 식별 및 관리 표준 운영 기준

by 날으는물고기 2026. 5. 11.

개인정보 및 중요정보 기반 DBMS 자산 식별 및 관리 표준 운영 기준

728x90

자산관리(Asset Management)를 효과적으로 수행하기 위한 근거, 기반, 방식, 운영 원칙, 실무 체크포인트를 정리하고, 보안 관점까지 포함해, 실제 정책·지침·운영절차·점검표의 뼈대로 쓸 수 있도록 구성하겠습니다.

1. 자산관리가 왜 중요한가

자산관리는 단순히 “목록을 적는 일”이 아니라, 회사의 보호 대상이 무엇인지 정확히 식별하고, 그 자산에 맞는 통제와 책임을 연결하는 활동입니다.

실무에서 자산관리가 중요한 이유는 크게 6가지입니다.

1) 보호 대상을 알아야 보안이 가능

무엇이 있는지 모르면 보호할 수 없습니다.
서버, DB, 계정, 애플리케이션, 클라우드 리소스, 데이터, API, 라이선스, 장비 등이 모두 자산입니다.

2) 위험평가의 출발점

위험은 자산을 기준으로 평가합니다.

  • 어떤 자산인가
  • 누구에게 중요한가
  • 어떤 데이터가 들어있는가
  • 외부에 노출되는가
  • 장애가 나면 어떤 영향이 있는가

즉, 자산이 정리되어 있어야 자산별로 위험도를 판단할 수 있습니다.

3) 보안통제의 기준선

접근통제, 로그수집, 암호화, 백업, 취약점 점검, 패치, 폐기 절차는 모두 자산 정보에 따라 달라집니다.

300x250

예를 들어

  • 개인정보가 있으면 암호화/접속기록/접근통제가 강화되어야 하고
  • 외부 서비스와 연계되면 네트워크 경계와 API 보호가 필요하며
  • 미사용 자산이면 폐기 검토가 필요합니다

4) 사고 대응 속도 향상

사고가 났을 때 가장 먼저 묻게 되는 질문은 다음입니다.

  • 이 자산이 어디에 있나
  • 누가 책임자인가
  • 어떤 서비스와 연결되어 있나
  • 백업이 있나
  • 영향 범위는 어디까지인가

자산대장이 없으면 사고 대응이 느려지고, 영향 분석이 부정확해집니다.

5) 감사/점검 대응의 기반

ISMS, 개인정보보호, 내부통제, 외부 감사에서 반복적으로 확인하는 것이 자산관리입니다.

자산별로 다음이 연결되어야 합니다.

  • 책임자
  • 용도
  • 중요도
  • 데이터 분류
  • 접근권한
  • 로그
  • 백업
  • 폐기 이력

6) 비용과 중복을 줄임

자산이 정리되면 중복 구매, 미사용 서버, 유령 DB, 방치된 계정, 과다 라이선스를 줄일 수 있습니다.
즉, 자산관리는 보안뿐 아니라 비용관리와 운영효율화에도 직접 연결됩니다.

2. 자산관리의 기본 기반

효과적인 자산관리는 아래 5개 기반 위에서 돌아갑니다.

1) 정책

“무엇을 관리할 것인가”를 정하는 상위 기준입니다.

  • 모든 정보자산은 등록해야 한다
  • 중요자산은 소유자와 책임자를 지정해야 한다
  • 개인정보를 포함한 자산은 별도 통제한다
  • 미사용 자산은 90일 내 정리한다

정책은 원칙이며, 예외는 최소화해야 합니다.

2) 표준

자산명, 분류 기준, 상태값, 책임자 정의, 중요도 기준 같은 것을 표준화합니다.

  • 상태값: 운영중 / 제한적사용 / 미사용 / 폐기예정
  • 중요도: 상 / 중 / 하
  • 유형: 서버 / DB / 네트워크 / 계정 / 애플리케이션 / 데이터

표준이 없으면 부서마다 다른 방식으로 입력되어 대장이 깨집니다.

3) 절차

등록, 변경, 검토, 폐기, 예외처리의 절차입니다.

  • 자산 생성 시 등록
  • 변경 시 승인 후 수정
  • 반기 1회 소유자 확인
  • 미사용 90일 초과 시 폐기 검토
  • 중요 자산은 분기 점검

4) 책임체계

누가 무엇을 책임지는지 명확해야 합니다.

  • 자산 소유자: 자산의 최종 책임
  • 운영책임자: 일상 운영 책임
  • 개발책임자: 시스템/애플리케이션 변경 책임
  • 보안담당자: 통제 기준 검토 및 점검
  • 자산관리 담당자: 대장 유지 및 품질관리

책임이 모호하면 자산은 금방 방치됩니다.

5) 도구

엑셀로 시작할 수도 있지만, 규모가 커지면 시스템화가 필요합니다.

  • 엑셀/시트
  • CMDB
  • ITSM/자산관리 시스템
  • 클라우드 태그 기반 관리
  • 자동 스캐닝 도구
  • 티켓/승인 시스템 연계

도구는 편의성보다 정확성, 최신성, 추적성이 더 중요합니다.

3. 자산관리를 잘하기 위한 핵심 원칙

자산관리는 아래 원칙을 지키면 훨씬 안정적으로 운영됩니다.

1) “등록”보다 “유지”가 중요

처음에 한 번 잘 만드는 것보다, 변경될 때 계속 최신 상태를 유지하는 것이 핵심입니다.

실무에서 가장 흔한 실패는

  • 초기에 대장 생성
  • 몇 달 뒤부터 미갱신
  • 실제와 대장 불일치
  • 결국 신뢰 상실

즉, 자산관리는 정적 문서가 아니라 살아있는 운영체계여야 합니다.

2) 자산은 “서버”만이 아니다

반드시 아래까지 포함해야 합니다.

  • 서버
  • DBMS
  • 애플리케이션
  • 계정
  • 인증서
  • 네트워크 장비
  • 클라우드 리소스
  • 스토리지
  • API
  • 데이터셋
  • 라이선스
  • 외주/협력사 제공 자산

특히 보안팀 입장에서는 데이터와 계정이 매우 중요합니다.

3) 자산은 “기술정보”만으로 부족하다

자산명, IP, 버전만 있으면 운영에는 쓸 수 있어도 보안 판단은 어렵습니다.

반드시 함께 봐야 하는 것

  • 무엇을 처리하는가
  • 개인정보가 있는가
  • 외부 연계가 있는가
  • 서비스 중요도는 어떤가
  • 장애 시 영향은 무엇인가
  • 누가 책임자인가
  • 얼마나 자주 사용되는가

4) 중요도는 기술이 아니라 영향 기준

예를 들어 CPU가 높은 서버가 중요 자산은 아닙니다.
오히려 CPU는 낮아도 고객정보를 처리하는 DB가 더 중요할 수 있습니다.

중요도 판단 기준은 보통

  • 기밀성
  • 무결성
  • 가용성
  • 법적/규제 영향
  • 고객 영향
  • 매출 영향
  • 대외 신뢰 영향

5) 자산은 “소유”와 “운영”을 구분

실무에서 매우 자주 혼동되는 부분입니다.

  • 소유자: 이 자산을 최종적으로 책임지는 사람
  • 운영자: 실제 운영하는 사람
  • 개발책임자: 기능/코드/구조를 바꾸는 사람
  • 승인권자: 폐기/변경을 승인하는 사람

이 구분이 있어야 변경 관리가 깨지지 않습니다.

4. 자산관리를 어떤 방식으로 운영해야 하는가

아래는 실무적으로 가장 많이 쓰는 운영 방식입니다.

1) 자산 생명주기 중심 관리

자산은 생성부터 폐기까지 단계가 있습니다.

자산 생명주기 예시

  1. 기획/도입
  2. 생성/구매
  3. 등록
  4. 운영
  5. 변경
  6. 점검
  7. 미사용 판정
  8. 폐기
  9. 증적 보관

이 생명주기별로 해야 할 일이 다릅니다.

  • 도입 시: 승인, 등록, 분류
  • 운영 시: 점검, 로그, 백업, 패치
  • 변경 시: 이력 관리
  • 폐기 시: 데이터 삭제, 계정 정리, 증적 확보

2) 자산 분류체계 중심 관리

모든 자산을 동일하게 관리하면 비효율적입니다.
중요한 자산부터 더 강하게 관리해야 합니다.

보통 분류 기준은 다음과 같습니다.

  • 유형: 서버/DB/계정/애플리케이션/네트워크/데이터
  • 중요도: 상/중/하
  • 데이터 민감도: 일반/내부/기밀/개인정보 포함
  • 노출도: 내부전용/외부노출/인터넷노출
  • 운영상태: 운영중/미사용/폐기예정

3) 통합대장 + 세부대장 구조

실무에서는 한 장에 다 넣기보다 계층적으로 관리하는 것이 좋습니다.

예시 구조

  • 자산총괄대장
    • 서버대장
    • DBMS대장
    • 계정대장
    • 네트워크장비대장
    • 인증서대장
    • 클라우드리소스대장
    • 데이터자산대장

이렇게 하면 항목이 많아져도 관리가 가능합니다.

4) 시스템 연계형 관리

자산정보는 다른 운영정보와 연결되어야 가치가 올라갑니다.

  • CMDB 연계
  • 모니터링 연계
  • 취약점 점검 연계
  • 계정관리 연계
  • 티켓/변경관리 연계
  • 백업 시스템 연계
  • 클라우드 태그 연계

즉, 자산대장이 단독으로 존재하기보다 운영 시스템들과 연결되어야 합니다.

5) 자동화 + 수동검증의 병행

자산관리는 자동화만으로 끝나지 않습니다.

자동화가 잘하는 것

  • IP/호스트/버전/태그 수집
  • 설치 여부 탐지
  • 접속 여부 추적
  • 사용현황 로그 수집

사람이 반드시 봐야 하는 것

  • 실제 서비스 목적
  • 책임자 지정
  • 개인정보 포함 여부
  • 중요도 판단
  • 폐기 판단
  • 예외 승인

즉, 자동 수집 + 사람의 확정 구조가 가장 현실적입니다.

5. 실무에서 꼭 필요한 자산관리 항목

자산관리 항목은 너무 적어도 안 되고, 너무 많아도 입력이 안 됩니다.
그래서 필수 항목 / 권장 항목 / 선택 항목으로 나누는 것이 좋습니다.

1) 필수 항목

최소한 아래는 있어야 합니다.

  • 자산ID
  • 자산명
  • 자산유형
  • 서비스명
  • 시스템명
  • 소유자
  • 운영책임자
  • 개발책임자
  • 위치(IP/호스트/클라우드)
  • 환경(운영/개발/테스트/DR)
  • 상태(운영중/미사용/폐기예정)
  • 중요도
  • 개인정보 포함 여부
  • 연계 여부
  • 비고
  • 등록일/최종변경일

2) 권장 항목

실무에서 매우 유용합니다.

  • 버전
  • OS
  • 포트
  • 설치 위치
  • 백업 여부
  • 암호화 여부
  • 접근통제 여부
  • 접속로그 수집 여부
  • EOS/EOL 여부
  • 외부노출 여부
  • 가용성 수준
  • 복구목표(RTO/RPO)
  • 대체 시스템 여부

3) 선택 항목

조직 성숙도에 따라 추가합니다.

  • 라이선스 정보
  • 공급사
  • 계약 만료일
  • 유지보수 담당
  • SLA
  • 장애이력
  • 취약점 이력
  • 정기점검 결과
  • 폐기일
  • 폐기 증적 링크

6. 자산관리에서 가장 중요한 판단 기준

아래 기준은 현업에서 특히 중요합니다.

1) 개인정보 포함 여부

보안 강도를 결정하는 핵심 기준입니다.

  • 주민번호, 연락처, 주소, 이메일, 계정정보, 결제정보
  • 고객 식별자와 업무 데이터가 결합된 경우도 주의 필요

개인정보 포함 여부에 따라

  • 암호화 필요 여부
  • 접근권한 수준
  • 로그 보관 수준
  • 반출 통제
  • 백업 보호 수준이 달라집니다

2) 서비스 연계 여부

DB나 서버가 단독으로 존재하는지, 여러 서비스가 붙어 있는지 확인해야 합니다.

연계가 많을수록

  • 장애 영향 범위가 커지고
  • 변경 위험이 증가하며
  • 접근통제와 네트워크 분리가 중요해집니다

3) 사용 여부

미사용 자산은 보안 리스크입니다.

미사용인데도 남아 있으면

  • 취약한 버전이 방치될 수 있고
  • 계정이 살아있을 수 있고
  • 백업과 로그가 남을 수 있으며
  • 공격자가 탐지하기 어려운 숨은 자산이 될 수 있습니다

따라서 미사용 자산은 반드시 폐기 검토 대상으로 두어야 합니다.

4) 사용 목적

목적이 분명해야 적절한 통제를 적용할 수 있습니다.

  • 회원DB
  • 주문DB
  • 로그DB
  • 통계DB
  • 임직원DB
  • 개발검증DB

목적이 불분명하면 보안통제도 애매해집니다.

7. 자산관리 운영 절차 예시

실무에서는 아래 흐름이 가장 많이 쓰입니다.

1) 도입/생성 시

  • 자산 생성 요청
  • 자산 유형 결정
  • 책임자 지정
  • 중요도 분류
  • 개인정보 포함 여부 확인
  • 연계 여부 확인
  • 자산대장 등록

2) 운영 중

  • 월간 또는 분기 점검
  • 변경사항 반영
  • 취약점 점검
  • 백업 및 로그 확인
  • 계정/권한 검토

3) 변경 시

  • 변경요청서 접수
  • 영향도 검토
  • 승인
  • 변경 수행
  • 결과 확인
  • 대장 갱신

4) 미사용 판정 시

  • 최근 사용 이력 확인
  • 서비스 오너 확인
  • 대체 시스템 존재 여부 확인
  • 폐기 계획 수립
  • 데이터 백업/이관/삭제
  • 폐기 완료 증적 저장

5) 폐기 시

  • 서비스 종료 공지
  • 데이터 보관/삭제 정책 적용
  • 계정 삭제
  • 인증서/키 폐기
  • 네트워크/방화벽 규칙 정리
  • 대장 상태 변경
  • 증적 보관

8. 자산관리를 잘하는 조직의 특징

성숙한 조직은 아래 특징이 있습니다.

1) 자산등록이 업무 흐름에 포함됨

“나중에 등록”이 아니라,
도입·개발·변경·폐기 프로세스에 자산등록이 들어가 있습니다.

2) 책임자가 명확함

자산마다 소유자와 운영자가 명확합니다.

3) 상태가 살아 있음

운영중, 제한적사용, 폐기예정, 미사용 같은 상태가 실제와 일치합니다.

4) 중요도 기반 통제가 있음

모든 자산에 같은 수준의 통제를 하지 않고, 중요도별로 차등 통제합니다.

5) 증적이 남음

언제 누가 무엇을 바꿨는지 남습니다.

6) 자동화가 일부 적용됨

수집 가능한 정보는 자동으로 모으고, 사람이 판단해야 할 부분은 승인 절차로 처리합니다.

9. 자산관리 실패 사례

실무에서 흔한 실패를 알아두면 설계가 쉬워집니다.

1) 등록만 하고 업데이트 안 함

가장 흔한 문제입니다.
대장이 실제와 다르면 결국 아무도 안 봅니다.

2) 담당자가 불명확함

책임이 없으면 수정도 없고 폐기도 없습니다.

3) 너무 많은 항목을 강제

입력 부담이 커지면 현업이 대장을 회피합니다.

4) 너무 적은 항목만 있음

기술정보만 있어서 보안 판단이 불가능합니다.

5) 상태값이 모호함

운영중인지 미사용인지 폐기예정인지 불명확하면 관리가 흐려집니다.

6) 클라우드/임시 자산 누락

온프레미스만 관리하고 클라우드 리소스, 테스트 DB, 임시 서버가 빠지는 경우가 많습니다.

7) 데이터 자산을 놓침

서버는 관리하면서 그 안의 데이터 중요도를 반영하지 않는 경우가 많습니다.

10. 실무적으로 추천하는 운영 모델

아래 방식이 가장 현실적입니다.

A. 1단계: 최소 필수 자산대장

엑셀이나 시트로 시작합니다.
목표는 “완벽”이 아니라 “누락을 줄이는 것”입니다.

B. 2단계: 중요자산 중심 관리

전 자산을 한 번에 완전 자동화하려 하지 말고,
먼저 중요 DB, 고객정보 시스템, 외부연계 시스템부터 정리합니다.

C. 3단계: 자동 수집 연계

  • 서버 탐지
  • DB 탐지
  • 버전 탐지
  • 태그 수집
  • 계정/권한 연계
  • 로그/백업 점검 연계

D. 4단계: 변경관리 통합

자산 변경이 티켓과 연결되면 대장이 훨씬 정확해집니다.

E. 5단계: 정기 검증 체계

분기별 또는 반기별로 소유자 확인을 해야 합니다.

11. 보안 관점에서 반드시 챙겨야 할 점검포인트

자산관리 문서나 대장에 아래 항목이 있으면 보안 품질이 높아집니다.

  • 개인정보 포함 여부
  • 외부 노출 여부
  • 서비스 연계 여부
  • 사용 여부
  • 중요도
  • 암호화 여부
  • 접근권한 관리
  • 로그 수집 여부
  • 백업 여부
  • EOS/EOL 여부
  • 책임자 지정 여부
  • 폐기 절차 존재 여부

특히 보안팀은 아래를 우선적으로 봐야 합니다.

보안 우선순위

  1. 개인정보/기밀 데이터 포함 자산
  2. 외부 노출 자산
  3. 중요 서비스 DB
  4. 운영자 권한이 큰 시스템
  5. 미사용인데 살아 있는 시스템
  6. EOS/EOL 장비 및 DBMS

12. 실무용 한 줄 정의

자산관리를 실무적으로 정의하면 이렇게 정리할 수 있습니다.

“회사가 보유·운영하는 모든 정보자산을 식별하고, 소유자와 중요도, 데이터 특성, 연계관계, 사용상태를 기준으로 지속적으로 최신화하여 보안·운영·감사에 활용하는 체계”

13. 바로 적용할 수 있는 운영 원칙 요약

아래 7가지만 지켜도 자산관리 수준이 크게 올라갑니다.

  1. 모든 자산은 등록한다
  2. 자산마다 책임자를 둔다
  3. 기술정보뿐 아니라 목적과 데이터도 기록한다
  4. 중요도와 개인정보 포함 여부를 반드시 본다
  5. 변경 시 대장을 수정한다
  6. 미사용 자산은 폐기 검토한다
  7. 정기 점검으로 실제와 대장의 차이를 줄인다
728x90
그리드형(광고전용)

댓글