클라우드 리소스는 모두 정보자산 관리대장에 등록해야 할까?

클라우드 리소스는 모두 정보자산 관리대장에 등록해야 할까?

— ISMS-P 2.1.3 정보자산 관리 관점에서 보는 클라우드 자산 식별과 책임소재

가상 시나리오 안내
이 글은 ISMS-P 정보자산 관리 기준을 이해하기 위한 가상의 사례를 바탕으로 작성했다. 기업명, 담당자, 자산 식별번호, 클라우드 리소스, 데이터 및 증적은 설명을 위해 임의로 구성했다. 실제 기업의 심사 결과나 특정 기업의 결함 사례가 아니다.

---

1. 클라우드 환경에서 정보자산 관리가 어려워지는 이유

전통적인 온프레미스 환경에서는 서버를 구매하고 설치한 뒤 자산관리대장에 등록하는 방식으로 정보자산을 관리하는 경우가 많다.

하지만 클라우드 환경에서는 자산의 생성과 변경 속도가 크게 달라진다.

예를 들어 개발자가 IaC(Infrastructure as Code)나 CI/CD 파이프라인을 통해 다음과 같은 리소스를 생성할 수 있다.

EC2
RDS
S3
EBS
Load Balancer
Lambda
EKS
Security Group
CloudFront

 

개발·테스트 환경에서는 이러한 리소스가 생성되었다가 며칠 또는 몇 시간 만에 삭제되기도 한다.

이 때문에 기존의 방식만으로는 클라우드 환경의 변화 속도를 따라가기 어려울 수 있다.

자산 도입
   ↓
자산번호 부여
   ↓
자산대장 등록
   ↓
소유자 지정

 

그렇다면 여기서 한 가지 질문이 생긴다.

클라우드에서 생성되는 모든 리소스를 기존 정보자산 관리대장에 하나씩 등록해야 할까?

이 질문에 단순히 "그렇다"고 답하는 것은 적절하지 않다.

중요한 것은 조직이 정보자산을 어떤 기준으로 식별하고 관리하도록 정했으며, 실제 클라우드 환경에서도 그 기준이 일관되게 적용되고 있는지를 확인하는 것이다.

---

2. 가상의 기업 및 운영환경

기업 개요

구분	내용
기업명	A사
서비스	프로젝트 관리 솔루션(PMS) SaaS
개인정보 보유 규모	약 45만 건
인프라	AWS + 온프레미스 하이브리드
아키텍처	Kubernetes 기반 MSA
주요 담당	인프라팀
주요 업무	클라우드 인프라 운영 및 자산관리

A사는 기존 온프레미스 데이터센터에서 AWS 중심의 클라우드 환경으로 인프라를 단계적으로 이전하고 있다.

마이그레이션 과정에서 개발·테스트·운영 환경이 동시에 변경되고 있으며, CI/CD 파이프라인을 통해 클라우드 리소스가 자동으로 생성되고 삭제되고 있다.

문제는 기존 정보자산 관리 절차가 이러한 변화 속도를 충분히 반영하지 못하고 있다는 점이다.

---

3. 기존 정보자산 관리 절차

A사의 정보자산 관리 절차는 다음과 같이 운영되고 있다고 가정한다.

신규 자산 도입
      ↓
자산 식별
      ↓
자산관리대장 등록
      ↓
중요도 분류
      ↓
소유자 지정
      ↓
보호대책 적용
      ↓
정기적인 현황 갱신

절차 자체에는 문제가 없어 보인다.

하지만 이 절차가 클라우드 리소스의 생성과 변경 과정과 연결되어 있는지가 중요하다.

A사는 신규 클라우드 리소스를 생성할 때마다 인프라팀에서 수동으로 자산관리대장을 갱신하도록 운영하고 있었다.

반면 실제 클라우드 환경에서는 DevOps 파이프라인을 통해 하루에도 여러 개의 리소스가 생성되고 있었다.

결과적으로 다음과 같은 차이가 발생하기 시작했다.

[관리체계]

자산 생성
   ↓
인프라팀 전달
   ↓
자산대장 등록

[실제 클라우드]

Git Commit
   ↓
CI/CD
   ↓
Cloud Resource 생성
   ↓
서비스 배포

두 과정이 서로 연결되어 있지 않은 것이다.

---

4. 현장 인터뷰

심사원

정보자산 식별과 자산별 소유자 지정은 어떤 절차로 이루어지고 있습니까?

인프라팀 김 과장

당사는 정보자산 관리 지침에 따라 신규 자산을 도입하면 자산 식별번호를 부여하고 자산관리대장에 등록합니다.

이후 해당 자산을 사용하는 부서를 확인하고 소유자를 지정합니다.

정기적으로 자산 현황도 갱신하고 있습니다.

심사원

최근 클라우드 전환으로 자산이 많이 증가했는데, 실제 AWS 환경과 자산관리대장은 어떤 방식으로 비교하고 있습니까?

김 과장

현재는 정기적으로 클라우드 콘솔을 확인하고 주요 운영자산을 대장에 반영하고 있습니다.

다만 개발이나 테스트 과정에서 자동으로 생성되는 임시 리소스까지 모두 수동으로 등록하기에는 현실적으로 어려움이 있습니다.

일부 리소스는 클라우드 콘솔에서만 확인되고 자산관리대장에는 별도로 등록되지 않는 경우도 있습니다.

심사원

그렇다면 자산관리대장에 등록되지 않은 리소스는 중요도가 낮다고 판단할 수 있습니까?

김 과장

그 부분을 명확하게 구분하는 기준은 아직 마련되어 있지 않습니다.

---

5. 여기서 중요한 것은 '미등록' 자체가 아니다

이 인터뷰에서 가장 먼저 확인해야 할 부분은 다음이다.

자산관리대장에 없는 리소스가 존재한다는 사실만으로 결함을 판단할 수 있는가?

 

반드시 그렇지는 않다.

 

예를 들어 다음과 같은 리소스를 생각해 볼 수 있다.

개발 테스트용 EC2
임시 EBS
일회성 Lambda
CI/CD 과정에서 생성되는 임시 리소스

 

이러한 리소스를 조직의 정보자산 관리 기준상 어떻게 분류하고 관리하는지는 조직의 절차와 자산관리 기준을 함께 확인해야 한다.

반면 다음과 같은 자산이라면 이야기가 달라진다.

고객 개인정보 DB
PMS 핵심 서비스 서버
인증 서버
중요 로그 저장소
백업 저장소
보안관제 시스템

 

이러한 중요 정보자산이 관리체계에서 누락되어 있고,

• 소유자가 지정되지 않았거나
• 중요도가 분류되지 않았거나
• 보호대책이 적용되지 않거나
• 정기적인 점검 대상에서도 제외된다면

정보자산 관리체계가 실제 운영환경을 제대로 반영하고 있는지 확인할 필요가 있다.

---

6. 현장 증적 ① — 클라우드 인벤토리

다음은 가상의 AWS 인벤토리 조회 결과다.

[Cloud Inventory]

Resource                         Environment      Owner
-------------------------------------------------------------
PMS-Core-DB                     Production       db-admin
Legacy-Sync-Worker              Migration        dev-team
PMS-Migration-Backup            Migration        infra-team
PMS-Web-01                      Production       service-team
PMS-API-02                      Production       service-team

 

이 중 일부 리소스에는 다음과 같은 관리정보가 설정되어 있었다.

Environment = Production
Service     = PMS-Core
Owner       = db-admin
AssetID     = UNREGISTERED

 

또 다른 리소스에서는 다음과 같이 확인되었다.

Environment = Migration
Service     = Legacy-Sync
Owner       = dev-team
AssetID     = NONE

 

여기서 단순히 AssetID = NONE이라는 결과만 가지고 결함을 확정해서는 안 된다.

먼저 조직의 자산관리 절차에서 해당 유형의 리소스를 어떤 범위로 관리하도록 정하고 있는지 확인해야 한다.

---

7. 현장 증적 ② — 정보자산 관리대장

가상의 정보자산 관리대장은 다음과 같았다.

[정보자산 관리대장]

자산번호       자산명              중요도    소유부서
---------------------------------------------------------
AST-001       사내 그룹웨어       상        경영지원팀
AST-002       PMS 인증서버       상        인프라팀
AST-003       고객 DB           최상      개발본부

 

관리대장의 최종 갱신일은 클라우드 전환이 본격화되기 이전이었다.

이 상태에서 AWS 인벤토리와 관리대장을 비교하자 다음과 같은 문제가 발견되었다.

실제 클라우드 환경
       │
       ├── 중요 운영자산
       ├── 개발/테스트 자산
       ├── 임시 리소스
       └── 백업/저장소
       
       ↓ 비교

정보자산 관리대장
       │
       ├── 기존 온프레미스 자산
       └── 일부 클라우드 자산

 

문제는 단순히 숫자가 맞지 않는다는 것이 아니다.

실제 보호해야 할 정보자산이 무엇인지 조직이 일관된 기준으로 식별하고 있는지 확인하기 어려운 상태라는 것이 핵심이다.

---

8. ISMS-P 2.1.3 정보자산 관리 관점

ISMS-P의 정보자산 관리에서는 정보자산의 용도와 중요도에 따른 취급 절차 및 보호대책을 수립·이행하고, 자산별 책임소재를 명확하게 관리하는 것이 핵심이다.

따라서 클라우드 환경에서는 단순히 다음과 같이 접근하는 것보다,

"AWS 리소스가 자산대장에 모두 등록되어 있는가?"

다음과 같이 질문하는 것이 적절하다.

"조직이 정의한 정보자산 관리 범위에 해당하는 클라우드 자산이 식별되고 있는가?"

"해당 자산의 중요도가 분류되어 있는가?"

"자산별 소유자와 책임소재가 명확한가?"

"중요 자산에 필요한 보호대책이 적용되고 있는가?"

"클라우드 자산의 생성·변경·삭제가 자산관리 절차에 반영되는가?"

이러한 관점에서 보면 정보자산 관리는 단순한 대장 관리 업무가 아니다.

---

9. 결함으로 판단할 수 있는 핵심 지점

이번 사례에서 보다 설득력 있는 결함 포인트는 다음과 같다.

핵심 문제

클라우드 환경에서 생성·변경되는 정보자산을 식별하고 소유자를 지정하는 관리체계가 실제 운영환경과 충분히 연계되지 않고 있었다.

예를 들어 고객 개인정보 DB가 실제 운영 중인데도,

자산대장 미등록
      +
소유자 미지정
      +
중요도 미분류
      +
보호대책 관리대상 제외

 

상태라면 단순한 문서 누락으로 보기 어렵다.

반면 개발 테스트용 임시 리소스가 별도의 기준에 따라 관리되고 있다면 반드시 기존 자산대장에 동일한 방식으로 등록해야 한다고 단정할 필요는 없다.

---

10. 결함보고서 형태로 정리하면

[결함] 클라우드 환경의 정보자산 식별 및 책임소재 관리가 실제 운영환경과 일치하지 않음

관련 기준

2.1.3 정보자산 관리

운영현황

A사는 온프레미스 환경에서 AWS 기반 하이브리드 환경으로 인프라를 전환하고 있으며, CI/CD 및 DevOps 환경을 통해 클라우드 리소스를 생성·변경하고 있다.

회사는 정보자산 관리 절차에 따라 자산별 중요도 및 소유자를 지정하고 자산관리대장을 정기적으로 갱신하고 있으나, 클라우드 리소스의 생성·변경 과정과 기존 자산관리 절차가 직접적으로 연계되어 있지 않다.

확인사항

클라우드 인벤토리와 정보자산 관리 현황을 비교한 결과, 일부 운영 리소스가 자산관리 체계에서 식별되지 않았으며, 일부 리소스는 소유자 또는 중요도 정보가 명확하게 관리되지 않고 있었다.

또한 클라우드 환경의 자산 변동사항을 정기적으로 식별하여 자산관리대장 및 관련 관리정보에 반영하는 기준이 명확하게 운영되고 있지 않았다.

판단 포인트

이에 따라 조직에서 관리 대상으로 정의한 정보자산에 대해 실제 클라우드 환경에서의 자산 식별, 중요도 분류 및 책임소재 지정이 적절하게 이루어지고 있는지 확인이 필요하다.

근거목록

• 클라우드 자산 인벤토리 조회 결과
• 정보자산 관리대장
• 정보자산 관리 절차서
• 클라우드 자산 생성·변경 절차
• 담당자 인터뷰
• 중요 자산별 소유자 지정 현황

---

11. 원인은 '클라우드가 많아서'가 아니다

문제의 원인을 단순히

"클라우드 리소스가 너무 많다."

라고 설명하면 개선방향도 단순히 인력을 늘리는 것으로 끝나기 쉽다.

실제 근본 원인은 다음에 가깝다.

기존 자산관리 절차
       ↓
수동 등록 중심
       ↓
클라우드 자동 생성
       ↓
관리 프로세스와 연결되지 않음
       ↓
자산 식별 지연
       ↓
소유자·중요도 관리 지연
       ↓
보호대책 관리 누락 가능성

 

즉, 자산관리 프로세스와 클라우드 자산 생성 프로세스가 분리되어 있다는 것이 핵심이다.

---

12. 정보자산 관리에서 가장 중요한 4가지

클라우드 환경의 정보자산 관리는 다음 네 가지 요소를 연결해서 보는 것이 좋다.

① 식별

무엇을 보호해야 하는지 식별한다.

EC2
RDS
S3
EKS
Backup

단순 리소스 목록을 확보하는 것에서 끝나지 않고 실제 업무와 데이터 관점에서 중요한 자산을 식별한다.

---

② 중요도

해당 자산이 조직에 얼마나 중요한지 분류한다.

예:

PMS 고객 DB
    ↓
개인정보 포함
    ↓
업무 중요도 높음
    ↓
높은 보호수준 필요

---

③ 책임소재

누가 해당 자산을 관리하고 보안상 책임을 가지고 있는지 확인한다.

예:

PMS DB
 ├── 서비스 오너
 ├── 인프라 담당
 └── DB 운영 담당

특히 클라우드에서는 "AWS가 운영하니까 AWS가 책임진다"는 식으로 자산 소유자를 대신할 수 없다.

클라우드 사업자가 제공하는 인프라와 조직이 운영하는 정보자산의 책임 범위를 구분해야 한다.

---

④ 보호대책

자산의 중요도에 따라 필요한 보호대책을 적용한다.

중요도 상
   ↓
접근통제
암호화
백업
모니터링
취약점 관리
변경관리

따라서 자산관리의 최종 목적은 대장을 최신 상태로 만드는 것이 아니라 식별된 자산에 필요한 보호대책이 실제로 적용되도록 하는 것이다.

---

13. 개선 방향 ① — 클라우드 인벤토리를 기준정보로 활용

수동으로 자산대장을 처음부터 작성하는 방식보다 클라우드 인벤토리를 자동으로 수집하는 구조가 적합하다.

예를 들어 다음과 같은 흐름을 구성할 수 있다.

AWS Resource Inventory
        ↓
자산 식별
        ↓
태그 확인
        ↓
Owner 확인
        ↓
Environment 확인
        ↓
중요도 분류
        ↓
자산관리 시스템 반영

AWS API 또는 CSP의 인벤토리 기능을 이용하면 현재 환경에 존재하는 리소스를 주기적으로 확인할 수 있다.

다만 클라우드 인벤토리 자체를 정보자산 관리대장과 동일한 것으로 보는 것도 적절하지 않다.

클라우드 인벤토리는 기술적인 리소스 목록이고, 정보자산 관리는 업무 중요도와 책임소재까지 포함하는 관리체계이기 때문이다.

---

14. 개선 방향 ② — 필수 태그 기준을 만든다

클라우드 자산에 다음과 같은 최소 관리정보를 부여할 수 있다.

Environment
Service
Owner
DataClass
Criticality
AssetID
ExpirationDate

예를 들어 운영 DB라면 다음과 같이 관리할 수 있다.

Environment = Production
Service     = PMS
Owner       = DB운영팀
DataClass   = PersonalInformation
Criticality = High
AssetID     = AST-2026-021

개발 테스트용 임시 리소스라면,

Environment = Development
Owner       = DevTeam
Criticality = Low
ExpirationDate = 2026-10-15

와 같이 관리할 수 있다.

이렇게 하면 자산관리의 핵심 정보가 클라우드 리소스와 함께 이동하게 된다.

---

15. 개선 방향 ③ — 자산 생성 단계에서 관리정보를 강제한다

더 효과적인 방법은 리소스 생성 이후에 찾아다니는 것이 아니라 생성 단계에서 관리정보를 요구하는 것이다.

개발자가 IaC 작성
       ↓
필수 태그 검증
       ↓
Owner 확인
       ↓
Environment 확인
       ↓
중요도 확인
       ↓
배포

필수 항목이 누락된 경우 배포 단계에서 예외를 발생시키는 방식도 검토할 수 있다.

다만 운영환경에서는 모든 리소스에 동일한 통제를 적용하기보다 자산 유형과 환경에 따라 필수항목을 정의하는 것이 현실적이다.

---

16. 개선 방향 ④ — 예외 자산을 관리한다

클라우드 환경에서는 모든 리소스를 동일한 기준으로 관리하기 어렵다.

따라서 다음과 같이 예외를 별도로 관리할 수 있다.

리소스상태예외 사유만료일담당자

Migration-EC2	임시	마이그레이션	2026-10-15	인프라팀
Test-RDS	테스트	개발환경	2026-10-10	개발팀
Backup-S3	운영	백업 목적	-	인프라팀

중요한 것은 예외가 존재하지 않도록 만드는 것이 아니라,

예외가 왜 존재하는지, 누가 책임지는지, 언제 종료되는지를 관리하는 것

이다.

---

17. 자동 점검 구조

자산관리 자동화는 다음과 같이 구성할 수 있다.

[Cloud Inventory]
       ↓
[Resource Collection]
       ↓
[Tag Validation]
       ↓
[Owner Validation]
       ↓
[Criticality Validation]
       ↓
[Asset Register Comparison]
       ↓
      ┌──────────────┐
      │              │
     정상           예외
      │              │
      ▼              ▼
   기록/갱신      담당자 알림
                     ↓
                  조치/예외승인

여기서 중요한 것은 미등록 리소스를 발견했다고 바로 차단하거나 삭제하는 것이 아니다.

먼저 다음을 판단해야 한다.

관리대상 자산인가?
      ↓
예외 자산인가?
      ↓
임시 자산인가?
      ↓
실제 서비스에 사용되는가?
      ↓
누가 소유하는가?

그 후 필요한 조치를 수행한다.

---

18. 자동화 예시

다음은 개념적인 점검 로직이다.

resources = get_cloud_resources()

for resource in resources:

    if not resource.owner:
        create_exception(
            resource,
            reason="Owner 미지정"
        )

    elif not resource.environment:
        create_exception(
            resource,
            reason="Environment 미지정"
        )

    elif resource.environment == "Production":
        check_asset_register(resource)

    elif resource.environment == "Migration":
        check_expiration_date(resource)

실제 운영환경에서는 사용하는 CSP와 자산관리시스템에 맞게 구현해야 한다.

핵심은 코드 자체가 아니다.

클라우드 환경의 변화가 정보자산 관리체계에 자동으로 전달되는 구조를 만드는 것이 목적이다.

---

19. 개선 후 어떤 증적을 남겨야 할까?

정보자산 관리 개선에서는 다음과 같은 증적을 확보할 수 있다.

정책·절차

• 정보자산 관리 절차
• 정보자산 분류 기준
• 정보자산 중요도 기준
• 자산 소유자 지정 기준
• 클라우드 자산 관리 기준
• 예외 자산 관리 절차

기술적 증적

• 클라우드 인벤토리 조회 결과
• Resource Tagging 결과
• 자산관리시스템 등록 현황
• 태그 검증 결과
• Owner 미지정 탐지 결과
• 예외 자산 목록
• 자산 변경 이력

운영 증적

• 정기 자산 점검 결과
• 신규 자산 등록 기록
• 자산 소유자 변경 기록
• 폐기 자산 기록
• 미등록 자산 조치 결과
• 예외 승인 기록

---

20. 심사에서 이어서 확인할 질문

정보자산 관리 현황을 확인할 때는 단순히 자산대장만 요청하는 것보다 다음 질문을 함께 확인할 수 있다.

Q1. AWS에서 새로운 리소스를 생성하면 자산관리팀은 어떻게 알 수 있는가?

수동 통보인지 자동 연계인지 확인한다.

Q2. 모든 클라우드 리소스를 정보자산으로 관리하는가?

조직의 자산관리 기준과 관리범위를 확인한다.

Q3. 임시 리소스는 어떻게 관리하는가?

임시 리소스의 생성 목적과 만료일, 담당자를 확인한다.

Q4. 운영 DB의 소유자는 누구인가?

부서 단위가 아니라 실제 책임소재가 명확한지 확인한다.

Q5. 자산의 중요도는 어떤 기준으로 결정하는가?

개인정보, 업무 중요도, 서비스 영향도 등을 고려하는지 확인한다.

Q6. 자산이 삭제되면 자산대장에서는 어떻게 처리하는가?

운영 종료와 자산관리 종료가 연결되는지 확인한다.

Q7. 자산관리대장과 실제 클라우드 환경의 차이를 어떻게 탐지하는가?

정기 점검인지 자동화인지 확인한다.

---

21. 이번 사례의 핵심 리스크

정보자산 관리가 제대로 되지 않으면 가장 먼저 발생하는 문제는 보안관리의 사각지대다.

예를 들어 고객 개인정보 DB가 자산관리 대상에서 빠져 있다면 다음과 같은 문제가 연쇄적으로 발생할 수 있다.

자산 미식별
   ↓
소유자 불명확
   ↓
중요도 미분류
   ↓
보호대책 적용 기준 불명확
   ↓
취약점 점검 누락 가능
   ↓
패치 및 변경관리 누락 가능
   ↓
사고 발생 시 책임소재 및 대응 지연

따라서 정보자산 관리는 단순한 행정업무가 아니라 다른 보안통제의 출발점이 된다.

---

22. 자주 발생하는 판단 오류

오류 1. "자산대장에 없으면 무조건 결함이다."

자산관리대상 범위와 조직의 자산 식별 기준을 먼저 확인해야 한다.

모든 기술적 리소스가 동일한 방식으로 정보자산 관리대장에 등록되어야 한다고 단정하기보다는, 보호가 필요한 정보자산이 관리체계에서 누락되지 않았는지를 확인하는 것이 중요하다.

---

오류 2. "AWS 리소스는 모두 자산번호를 가져야 한다."

조직이 어떤 자산 식별체계를 사용하는지 먼저 확인해야 한다.

클라우드 리소스 ARN, 태그, CMDB ID, 서비스 ID 등 여러 식별자를 조합하여 관리할 수도 있다.

중요한 것은 식별자가 하나인지 여부가 아니라 자산을 추적할 수 있고 책임소재와 연결되는지다.

---

오류 3. "실시간으로 자산대장과 AWS가 100% 일치해야 한다."

클라우드 환경에서는 리소스가 지속적으로 생성·변경·삭제된다.

따라서 실시간 일치 여부 자체를 요구사항으로 단정하기보다는 조직이 정한 주기와 방법에 따라 자산 변동을 식별하고 관리하는 통제가 실제로 작동하는지를 확인하는 것이 적절하다.

---

오류 4. "태그만 있으면 자산관리가 끝난다."

태그는 중요한 관리수단이지만 자산관리 자체와 동일하지 않다.

다음 정보가 실제 업무와 연결되어야 한다.

리소스
 ↓
서비스
 ↓
정보자산
 ↓
중요도
 ↓
소유자
 ↓
보호대책

---

오류 5. "클라우드 콘솔에 있으니 관리되고 있다."

클라우드 콘솔에서 리소스를 조회할 수 있다는 것과 조직의 정보자산 관리체계에서 해당 자산을 관리하고 있다는 것은 다른 문제다.

특히 소유자, 중요도, 보호대책, 변경이력 등이 관리되지 않는다면 별도의 관리체계가 필요하다.

---

23. 실무 점검 체크리스트

정보자산 식별

• 조직의 정보자산 관리 범위가 정의되어 있는가?
• 클라우드 환경이 정보자산 관리 범위에 포함되어 있는가?
• AWS 등 클라우드 인벤토리를 정기적으로 확인하는가?
• 중요 정보가 저장된 자산을 식별할 수 있는가?
• 개발·테스트·운영 자산을 구분하고 있는가?

중요도 관리

• 자산 중요도 분류 기준이 존재하는가?
• 개인정보 포함 여부를 확인하는가?
• 서비스 중요도를 반영하는가?
• 중요도에 따라 보호대책이 달라지는가?

책임소재

• 자산별 소유자가 지정되어 있는가?
• 소유자가 변경될 경우 관리정보가 갱신되는가?
• 운영팀·개발팀·보안팀의 역할이 구분되어 있는가?

클라우드 운영

• 신규 리소스 생성 시 관리정보가 부여되는가?
• 필수 태그 기준이 존재하는가?
• Owner 태그 또는 이에 준하는 책임정보가 있는가?
• 임시 리소스의 만료일을 관리하는가?
• 미등록 또는 관리정보 누락 리소스를 탐지하는가?
• 예외 리소스를 별도로 관리하는가?

변경 및 종료

• 리소스 변경 시 자산정보도 갱신되는가?
• 리소스 삭제 시 자산관리 상태도 종료되는가?
• 자산관리대장과 실제 클라우드 환경을 정기적으로 비교하는가?
• 불일치 사항에 대한 조치 이력이 남아 있는가?

---

24. 이 사례에서 얻을 수 있는 핵심 교훈

클라우드 환경에서 정보자산 관리의 핵심은 자산관리대장을 최신 상태로 만드는 것 자체가 아니다.

더 중요한 것은 다음의 연결이다.

클라우드 리소스
      ↓
정보자산 식별
      ↓
중요도 분류
      ↓
소유자 지정
      ↓
보호대책 적용
      ↓
변경사항 관리
      ↓
종료 및 폐기

기존 온프레미스 환경에서는 사람이 자산을 등록하면서 이 과정이 자연스럽게 연결되었다.

하지만 클라우드에서는 다음과 같이 움직인다.

개발자
  ↓
Git
  ↓
CI/CD
  ↓
Cloud Resource

따라서 클라우드 리소스의 생성·변경 프로세스 자체를 정보자산 관리체계와 연결하는 것이 중요하다.

---

25. 마무리

클라우드 환경에서는 정보자산의 생성과 변경이 빠르게 발생한다.

이 때문에 기존의 수동 자산관리 방식만으로는 실제 환경을 정확하게 파악하기 어려울 수 있다.

하지만 이를 단순히

"자산관리대장에 모든 AWS 리소스를 등록해야 한다."

라고 접근하는 것도 적절하지 않다.

ISMS-P 2.1.3 관점에서 보다 중요한 질문은 다음과 같다.

보호해야 할 정보자산을 식별하고 있는가?

자산의 중요도를 적절하게 분류하고 있는가?

자산별 책임소재가 명확한가?

중요도에 따른 보호대책이 적용되고 있는가?

클라우드 환경의 생성·변경·삭제가 정보자산 관리체계에 반영되고 있는가?

이번 사례에서 발견된 문제도 결국 "자산대장의 숫자가 맞지 않는다"는 문제가 아니다.

핵심은,

실제 클라우드 환경에서 운영되는 정보자산을 조직의 관리체계가 적시에 식별하고, 중요도와 책임소재를 연결하며, 필요한 보호대책을 적용할 수 있는 구조를 갖추고 있는가

에 있다.

따라서 클라우드 환경의 정보자산 관리는 다음과 같은 구조로 발전시키는 것이 바람직하다.

[Cloud Inventory]
       ↓
[자산 식별]
       ↓
[중요도 분류]
       ↓
[소유자 지정]
       ↓
[보호대책 적용]
       ↓
[정기 검증]
       ↓
[변경·종료 관리]

결국 정보자산 관리의 목적은 자산관리대장을 채우는 것이 아니라, 보호해야 할 자산을 빠뜨리지 않고 책임과 보호대책을 연결하는 것이다.

---

한 줄 정리

클라우드 정보자산 관리는 모든 리소스를 수동으로 대장에 등록하는 문제가 아니라, 보호가 필요한 정보자산을 식별하고 중요도·소유자·보호대책을 실제 클라우드 환경과 연결하는 관리체계를 만드는 문제다.

---

참고자료

• ISMS-P 인증기준 — 2.1 정책, 조직, 자산관리
• ISMS-P 인증기준 안내서
• ISMS-P 세부점검항목
• 정보보호 및 개인정보보호 관리체계(ISMS-P) 운영 관련 자료
• AWS Resource Groups Tagging API 및 클라우드 자산 관리 관련 기술문서