[ISMS 2영역] 보호대책 요구사항에 대한 정리 2

서론

이 글은 학습과정에서 이해한 내용에 대한 개인적인 이해입니다.

[카테고리에 대한 설명]

 

오늘은 ISMS 2 영역에서 기술적인 부분에 대해 다룬다.

2.1 ~ 2.4까지는 1 영역의 정책이 실제로 업무에 적용되는지,

사람이나 공간, 기기에 대한 관리가 이루어지는지를 점검했다면

2.5부터는 기술적인 내용으로 들어간다.

 

오늘 다룰 내용은 기술적인 내용 중에서도

인증과 접근통제와 관련된 부분만을 정리할 예정이다.

 

2.5 인증 및 권한관리

지금까지 2.1 ~ 2.4에서는
사람이나 공간, 내부 정책에 대한 점검을 다뤘다면

 

2.5부터는
시스템에 대한 점검으로 들어간다고 이해했다.

 

2.5는 크게 세 가지로 나누어 생각할 수 있는데,
바로 식별, 인증, 권한이다.

 

이 구분은
ISMS뿐만 아니라
인증과 접근 통제를 설계하는 거의 모든 영역에서
공통적으로 사용된다고 생각했다.

식별

식별은 시스템을 사용하는 사용자를 구분하는 과정이다.

ISMS에서는 개인별 계정 사용을 권장하는데,
이는 시스템에서 발생하는 모든 행위의 주체를 명확히 하여
책임 소재를 분명히 하기 위함이라고 이해했다.

이를 위해,
서비스에서 제공하는 기본 계정을 변경하여 사용하는지,
공용 계정을 허가 없이 사용하지 않도록 관리하고 있는지,
외부 인력이 별도의 승인 절차 없이
개인 계정처럼 시스템을 이용하고 있지는 않은지 등을 점검할 필요가 있다.

결국 식별 단계에서는
누가 어떤 행위를 했는지를 추적할 수 있도록
계정이 개인 단위로 안전하게 관리되고 있는지가 핵심이라고 생각했다.

 

인증

인증은 식별된 사용자가 실제로 본인인지 확인하는 절차이다.

인증 수단에는 비밀번호, OTP, 인증서, MFA 등이 있으며,
인증 방식과 적용 대상을 정책으로 정의해야 한다.

인증 절차가 안전하게 운영되기 위해서는
로그인 실패 횟수 제한, 접속 유지 시간 관리,
동시 접속 제한 등 인증 오남용을 방지하기 위한 통제가 필요하다.

또한 비밀번호 및 인증 정보는 안전하게 관리되어야 하며,
도난이나 유출이 의심되는 경우 즉시 변경하는 절차가 마련되어 있어야 한다.

권한

권한은 인증된 사용자가
어떤 자산을, 어디까지 접근할 수 있는지를 통제하는 요소이다.

ISMS에서는 업무별로 권한을 분리하여 관리하고,
관리자 권한은 최소한으로 부여할 것을 요구한다.

또한 권한의 부여, 변경, 회수 과정에는
승인 절차가 마련되어 있어야 하며,
한 번 부여된 권한이 그대로 방치되지 않도록
주기적으로 권한 상태를 점검해야 한다.

결국 권한 관리는
사용자가 자신의 업무 범위를 넘어
불필요한 자산에 접근하지 못하도록 통제하는 목적이라고 이해했다.

---

2.6 접근통제

2.5에서는 사용자를 식별하고,

인증하는 과정을 점검했다면

2.6은 그 이후에 어디까지 접근을 허용할지에 대한 점검이다.

 

2.5가 계정에 부여된 권한을 다룬다면,
2.6은 그 권한이 실제 시스템과 네트워크 설정을 통해
강제되고 있는지를 점검하는 항목이라고 이해했다.

 

접근 통제는 단일한 기술이나 설정으로 이루어지지 않는다.
동일한 권한을 가진 사용자라 하더라도
접근 위치, 접근 방식, 접근 대상에 따라
위험도가 달라질 수 있기 때문에
접근 통제는 여러 관점에서 나누어 살펴볼 필요가 있다고 생각했다.

 

이러한 관점에서 2.6의 접근 통제는
접근 위치, 접근 경로, 접근 자원이라는
세 가지 통제 요소로 나누어 볼 수 있다고 생각했다.

 

접근 위치 통제

접근 위치 통제는
자산에 접근이 허용되는 위치를 제한하는 것을 의미한다.

같은 권한을 가진 사용자라 하더라도
내부망에서의 접근과 외부망에서의 접근은
위험도가 다르기 때문에

접근 가능한 위치에 대한 구분과 통제가 필요하다고 이해했다.

 

이를 위해 내부망과 외부망의 구분,
지정된 IP로의 접근 제한,
VPN 사용 여부와 같은 기준을 통해
자산에 접근할 수 있는 위치를 통제해야 한다.

접근 경로 통제

접근 경로 통제는
자산에 도달하는 방식 자체를 제한하는 통제라고 이해했다.

 

동일한 자산이라 하더라도
웹을 통한 접근, API 호출,
SSH를 통한 직접 접속이나
DB에 대한 직접 접근은
요구되는 통제 강도가 다르기 때문이다.

 

따라서 각 자산에 대해
허용된 접근 경로가 무엇인지 정의하고,
정의되지 않은 방식의 접근을 통제해야 한다고 생각했다.

접근 자원 통제

접근 자원 통제는
사용자가 실제로 접근 가능한 자산의 범위를 제한하는 것을 의미한다.

 

모든 자산이 동일한 중요도를 가지는 것은 아니기 때문에
서버, DB, 파일, 관리자 기능 등
각 자산의 중요도에 따라
접근 가능 여부와 범위를 구분해 통제해야 한다고 이해했다.

---

 

접근 통제는 이러한 통제 요소를
단일 지점에서만 적용하는 것으로는 충분하지 않다.

따라서 접근 통제는
네트워크, 시스템, 애플리케이션 등
서로 다른 계층에서 중첩적으로 적용되어야 한다고 생각했다.

네트워크 기반 통제

네트워크 기반 통제는
방화벽, 보안 그룹, ACL, VPN 정책 등을 통해
자산에 대한 접근을 네트워크 단에서 제한하는 방식이다.

 

이를 통해 허용되지 않은 위치나 경로에서의 접근을
사전에 차단할 수 있다고 이해했다.

시스템 기반 통제

시스템 기반 통제는
운영체제 접근 권한, 파일 권한,
서비스 포트 제한과 같은 설정을 통해
자산에 대한 접근을 시스템 단에서 제한하는 것이다.

 

이는 네트워크 통제를 우회하더라도
시스템 내부에서 접근을 한 번 더 통제하기 위한 단계라고 이해했다.

애플리케이션 기반 통제

애플리케이션 기반 통제는
URL 접근 제한, API 권한 검사,
관리자 페이지 접근 제한과 같이
애플리케이션 로직을 통해 접근을 통제하는 방식이다.

 

이를 통해 사용자에게 부여된 권한이
애플리케이션 기능 단위에서도
정확히 적용되고 있는지를 확인할 수 있다고 이해했다.

---

2.7 암호화

2.5, 2.6에서

각각 사용자의 계정과 인증,

자산에 대한 접근 통제를 다뤘다면

2.7은 암호화와 관련된 내용을 다룬다.

 

아무리 접근통제나 권한 관리를 잘해도

정보가 암호화가 되어 있지 않다면

통신 중이거나 저장된 상태에서

노출될 가능성이 매우 높아진다.

 

암호화와 관련된 내용은

크게 총 세 가지로 나눌 수 있다고 이해했다.

데이터가 흐를 때(통신),

데이터가 정지할 때(저장),

암호화 키 관리이다.

데이터가 정지할 때 (At Rest)

데이터가 정지한다는 것은

파일이나 디스크, DB 등으로 데이터가 흐른 뒤,

저장되어 멈춰있는 상태를 말한다.

 

다시 말해 

 

DB, 파일, 백업, 로그,

개인 PC 및 업무용 노트북 등에

저장되어 있는 자산과 관련된 정보들이

암호화가 되어있는지를 점검하는 항목이다.

 

ISMS에서는 이 정보가 노출되었을 때

바로 내용을 확인할 수 있는지,
아니면 복호화 과정을 거쳐야만
확인이 가능한지를 판단하는 것으로 이해했다.

 

예상을 해보자면 복호화 과정을 통해

시간을 번 뒤, 대처방안을 실행하기 위함이라고 생각된다.

 

데이터가 흐를 때 (In Transit)

데이터가 흐른다는 것은

통신을 통해 데이터가 이동하는 것을 의미한다.

 

이 경우
외부망과 내부망을 모두 포함하여
암호화 통신이 이루어져야 한다고 이해했다.

 

외부망에서 접속 시 반드시 VPN을 사용하여

내부망에 접근해야 한다고 이해했다.

 

또한

API 호출이나 웹 통신 역시
암호화되지 않은 상태로 데이터가 전달되지 않도록,

 

최신 버전의 HTTPS, TLS 등을 사용하여
통신 내용이 암호화되어야 한다고 이해했다.

 

암호키 관리

암호키는 암호화의 핵심이다.

 

암호키가 유출되면

그 즉시

해당 키를 사용하는 모든 암호화를
다시 구성해야 할 정도로

암호키에 대한 관리는 중요하다.

 

ISMS에서는

암호키 자체를 보는 것이 아니라

암호키에 대한 생애주기를 관리하는 정책이

수립되어 있는지를 점검하는 것처럼 느껴졌다.

 

예를 들어

• 키의 담당자가 누구인지,
• 생성 절차는 무엇인지,
• 보관은 어디에 하는지,
• 배포 방법은 무엇인지,
• 사용 기간, 변경주기는 어떤지,
• 복구 및 폐기 절차는 있는지,
• 소스 코드에 하드코딩을 하지는 않는지 등

이러한 항목들을 통해
암호키가 체계적으로 관리되고 있는지를
점검하는 것이라고 이해했다.

 

정리하자면

암호키는
안전한 알고리즘을 통해 생성되어야 하고,
안전한 장소에 보관되어야 하며,
접근 권한은 최소화되어야 한다.

 

또한
주기적으로 모니터링되어야 하고,
일정 기간마다 재생성되어야 하며,
폐기 절차 역시 정해져 있어야 한다고 이해했다.

---

후기

오늘도 ISMS 2 영역 중 일부에 대한 내용을 정리해 보았다.

 

기술적인 내용을 점검하다 보니
알고리즘 이름과 같은
어려운 단어들을 의도적으로 빼고 정리하니
그 결과 내용이 다소 비어 보일 수 있겠다는 생각도 들었다.

 

그래도 먼저 큰 그림을 이해하고,
그 위에 단어와 세부 내용을 나중에 얹는 방식이
나에게는 더 잘 맞는 학습 방법이라고 느껴
이 방향을 그대로 유지하려고 한다.

 

또한
ISMS에서 증거물로 요구하는 것이
대부분 해당 과정에 대한 기록물과
설정 파일이라는 점 때문에
글에서는 점점 그 부분을 직접 언급하지 않게 되는 것 같다는 생각도 들었다.

 

나중에 다시 글로 옮기거나 정리할 때는
이 부분을 조금 더 의식해서 보완해야 할 것 같다.