제로 트러스트 아키텍처 On-premise 리눅스 서버 1

아무것도 믿지 말라라는 컨셉에서 시작한 ZTA(Zero Trust Archictecture) 라는게 모든 권한을 빼고 JIT(Just In Time) 필요할때만 주자 그리고 모든것을 감시하자라는 의미입니다. 

 

그럼 On-premise 리눅스 서버를 대상으로 제로 트러스트 아키텍처 정책을 하나 소개하고자 합니다. 

 

아키텍처에 대해 설명하자면 대상 서버들은 Vault 라는 접근제어,권한제어 솔루션을 통해서만 접근이 가능합니다. 모든 리눅스 서버의 inbound ssh port 는 Vault 가 됩니다. 이를 통해 대상 서버로 접근가능한 경로는 오직 하나뿐이게 됩니다. 

 

Vault에 로그인하기 위해서 AD 을 연동하게 됩니다. AD의 인사정보를 연동한 후 크게 3개의 그룹(외주,개발,운영) 내 속한 계정은 Vault 에 로그인 하게 됩니다. 로그인은 자신의 AD 계정의 아이디/패스워드를 그대로 사용하게 되며 OTP 등의 MFA 인증을 거쳐야 로그인에 성공하게 됩니다.

 

로그인 이후 접근 권한이 부여된 대상 서버 항목들만 공개되게 됩니다. 예를 들어 개발그룹에 속한 계정으로 Vault 에 로그인 한 경우, 개발계에 속한 서버들만 공개되며 이 서버들에만 접속이 가능합니다. 

 

개발계와 운영계 서버들에는 각 2개씩의 계정이 존재합니다. 예를 들어 개발서버에는 dev_account, ext_account 가 존재하며 운영계 서버들에는 man_account, ext_account 가 존재합니다. 그리고 개발그룹에 속해 있다면 dev_account 계정만 접속이 허용되며, 외주인력에게는 ext_account, 운영인력에게는 man_account 만 접근이 허용됩니다. 

 

각 계정의 패스워드는 Vault 에 의해 관리되며 특정일을 기준으로 랜덤화 됩니다. 즉 사용자에게 SSO로 접속은 가능하지만 패스워드를 공개하지 않습니다. 

 

각 계정들에게는 sudo 권한을 전부 부여한 것이 아닌 각 역할에 맞는 명령어들만 허용되게 설정되어 있는 상태입니다. 

 

 

각 계정들은 역할에 맞게 필요한 명령어만 입력이 가능합니다. (굉장히 러프한 예시입니다)

그리고 그외의 명령어를 입력해야 할 경우에는 관리자에게 요청/승인을 통해 가능합니다. 그리고 사용자가 대상 서버에 접근한 내역과 작업내용은 모니터링 되게 됩니다. 마찬가지로 개발인력에 예외적으로 운영계 서버에 접속하기 위해서는 관리자의 승인을 받으면 일시적으로 접근이 가능합니다. 

 

위 과정을 사용자의 입장에서 보자면, 

1. 본인의 사번을 이용해 Vault에 MFA 을 인증 후 로그인

2. 접속하고자 하는 서버에 접속 허용된 계정으로 ssh 접속 후 작업

3. 허용된 계정이 가지지 못한 권한이 필요하면 관리자에게 요청/승인 후 일시적으로 사용 가능  

4. 모든 접속이력과 작업내역은 기록되고 모니터링 됨

 

가장 기본적인 형태의 정책을 소개해봤습니다. 여기서 보안의 강도를 조금 더 높이자면 

1. Vault 로그인 후 서버에 접근 시 또는 sudo 권한 사용 시 MFA 적용

2. 서버 접근과 sudo 권한 사용 시간을 근무 일정에 맞춰 월-금 9-6 까지만 적용 그 외에는 요청/승인 작업 필요함

위와 같이 월-금 9-6에만 접근, 권한 사용을 허용하게 할 수 있습니다. 

 

3. 권한의 경우 단순 명령어 제어 뿐 아니라 읽기/쓰기/실행 권한까지 조절

 

제로 트러스트 아키텍처의 컨셉에 맞게 간다면, 모든 사용자는 접근, sudo 명령어 그 어떤 것도 실행이 불가능 한 상태에서 요청/승인 과정을 거쳐 정해진 시간만큼(Just In Time)만 허락되게 할 수 있지만 이 경우 관리자에게 몰리는 수많은 요청세례 그리고 사용자는 일일히 신청을 해야하는 번거로움이 생깁니다. 즉 보안의 강도는 생산성과 보안을 동시에 고려해 적절한 선에서 조절할 필요가 있습니다. 

 

가트너에서 말하는 계정관리의 나쁜 예를 보자면 아래와 같습니다. 

1. 여러 소프트웨어, 운영체제에 동일한 이름의 계정을 사용하는 것

2. 여러 계정에 동일한 패스워드를 사용하는 것

3. 패스워드를 메신저,문자,문서에 평문으로 저장해 공유하는 것

4. 다수에게 하나의 계정이 공유되는 것

5. 사용자에게 여러개의 계정을 관리하도록 하는 것

 

 제가 언급한 정책의 경우 1,4번의 항목을 침해하지만 나름의 대응을 가지고 있습니다. 

1. 여러 소프트웨어, 운영체제에 동일한 이름의 계정을 사용하는 것

 -> 동일한 이름의 계정을 사용하지만 패스워드가 공개되지 않고 관리된다.

2. 여러 계정에 동일한 패스워드를 사용하는 것

-> 패스워드는 각기 다르게 랜덤화 된다.

3. 패스워드를 메신저,문자,문서에 평문으로 저장해 공유하는 것

-> 사용자는 패스워드를 모르기 때문에 공유할 수 없다.

4. 다수에게 하나의 계정이 공유되는 것

-> 하나의 계정이 공유되지만 Vault 가 관리하고 누가 이 계정을 사용한지를 추적할 수 있다.

5. 사용자에게 여러개의 계정을 관리하도록 하는 것

-> 사용자는 오직 자신의 사번 계정 하나만 관리하면 된다.

 

제로 트러스트 아키텍처를 이용해 On-premise 리눅스 서버들을 대상으로 한 러프한 정책 하나를 소개했습니다. 상황에 따라서 보안의 강도에 따라 정책이 달라질 수 있음을 유의하시기 바랍니다.