운영망, 개발망 분리 요건에서는 네트워크 분리뿐만 아니라 사용자 분리도 필요합니다. 이때, 권한 분리를 통해 통제할 수 있습니다.

클라우드 환경에선 권한을 부여하는 방식이 2가지로 나뉩니다. 각 특성은 아래와 같습니다.

1. RBAC(Role-Based Access Control): 각 개인이 시스템에 접근할 수 있는 권한을 역할 기준으로 통제하는 것입니다.
   1. 사용자나 사용자가 속한 그룹에 역할을 할당하여 접근을 제어하는 방식입니다.
   2. 사용자가 해당하는 역할에 따라 자원에 대한 접근을 제어합니다.

2. ABAC(Attribute-Based Access Control): 시스템에 접근할 수 있는 권한을 사용자, 리소스 속성, 환경에 따라 통제하는 것입니다.
   1. 객체에 접근하기 위해 속성을 정의하고, 해당 객체에 접근하려는 주체가 그 속성을 가지고 있는지 검사한 후 접근 제어를 수행합니다.
   2. 속성은 주체의 이름, 자원에 대한 유형 등 다양하며 지원 종류는 서비스 혹은 플랫폼에 따라 상이합니다.

ABAC로 접근 권한을 통제하면 세분화된 권한을 사용할 수 있고 시스템의 다양한 요소 반영이 가능하지만, 많은 시간과 자원이 필요합니다.

RBAC는 정의된 역할에 대한 권한 분리가 가능하기 때문에 효율적으로 권한을 부여, 회수할 수 있습니다. 그렇기 때문에 RBAC를 기반으로 권한 분리를 진행하였습니다.

일반적으로 운영 서버에는 개발자 접속을 허용하지 않습니다. 하지만, 시스템 장애 등 얘기치 못한 사건들로 인해 접근이 필요한 상황이 발생합니다. 또한, 운영자 별로도 접속이 필요한 서버가 상이하며, 필요한 권한도 다릅니다. 이때 사용자 별 그룹을 나눠 그룹에 맞는 권한 부여로 접근 권한을 관리할 수 있습니다.

회사 내부에 접근 제어 솔루션이 있는 경우 해당 제품을 통해 권한 분리 및 설정이 자유자재로 가능합니다. 하지만 솔루션 구축 없이 리눅스 OS의 자체 기능만 가지고 계정 별 권한 분리가 가능합니다.

파일 권한 제거

우선 해당 방식을 사용하기 위해선 setuid, setgid 설정되어 있는 파일의 권한을 제거해야 합니다.

setuid가 적용된 파일을 실행하면 실행 파일이 끝날 때까지 파일 소유자의 UID가 되는 것입니다. setuid가 설정되어 있는 root의 파일을 실행하면 실행이 끝날 때까지 실행하는 사용자의 UID가 root의 UID인 0이 되어 root 권한을 가지게 됩니다. 마찬가지로 setgid는 적용된 파일을 실행하면 실행 파일이 끝날 때까지 파일 소유 그룹의 GID가 되는 것입니다.

1. setuid, setgid 파일 확인

find / -user root -type f \( -perm -4000 -o -perm -2000 \) -exec ls -la {} \;

2. 조치 방법

chmod -s [file name]

• 해당 설정 사용이 반드시 필요한 경우 특정 그룹에서만 사용하도록 제한하는 방법이 있습니다. (일반 사용자의 setuid 사용 제한, 임의의 그룹만 가능)

chgrp [group name] [setuid file name]
chmod 4750 [setuid file name]

추가로 계정 임계 설정도 필요합니다. 2020년 KISA에서 발표한 “클라우드 취약점 점검 가이드”를 적용하였다면 이미 완료된 보안 설정일 수도 있으나 여러 사용자가 운영 서버에 접근하는 경우 계정별 임계 설정 여부를 한 번 더 확인하는 것이 좋습니다.

/etc/pam.d/common-auth

auth		required		pam_tally2.so onerr=fail even_deny_root deny=5 unlock_time=600

auth    required    pam_faillock.so preauth silent audit deny=5 unlock_time=600

# OS 버전에 따라 사용하는 버전이 다르므로 버전 확인이 필요합니다.

또한, 세션 타임아웃 설정도 필요합니다. 일반적으로 10분을 권장하고 있으나 회사 내부 정책에 따라 조절하셔도 됩니다.

/etc/profile

export TMOUT=300

해당 조치가 완료되었다면, 사용자 별 권한 그룹을 나눕니다.

와탭랩스는 데브옵스팀, 개발팀 2개의 그룹으로 나누었으며 일반 명령어는 사용할 수 있으나 sudo 명령어에 제한을 두었습니다.

devops 그룹은 전체 운영을 관제하며 장애 처리를 진행하고 있으므로 명령어에 제한을 두지 않았습니다. 개발팀은 장애 파악 외의 별도 작업을 하고 있지 않기 때문에 아래 명령어만 허용해 두었습니다.

cat, ps, df, du, netstat, curl

와탭 모니터링 툴로 로그 확인이 충분히 가능하므로 로그 확인을 위한 명령어는 허용하지 않았으며, 서버 설정 파악을 위해 cat은 허용해 두었습니다.

1. 개발자 그룹 생성

groupadd dev

2. 그룹별 sudo 권한 설정

/etc/sudoers

%dev ALL=NOPASSWD:/usr/bin/cat, /usr/bin/ps, /usr/bin/df, /usr/bin/du, /usr/bin/netstat, /usr/bin/curl
# 명령어별 전체 경로는 which 명령어를 통해 확인할 수 있습니다.

권한 부여 과정은 다음과 같습니다.

1. 개발팀의 권한 요청을 확인합니다.
   1. 접속 서버, 이유, 접속 기간이 포함되어야 합니다.
   2. 개발팀장, 데브옵스 팀장의 승인이 있어야 합니다.

2. 요청된 권한의 정당성을 확인합니다.

3. 개발팀의 권한 요청이 오면 해당 인원의 계정을 우선 생성합니다.

useradd -g dev [user name]
usermod -aG dev [user name]

접근 제어 솔루션을 이용하는 경우 좀 더 쉽게 권한 분리가 가능하나 리눅스 OS의 기능을 이용하여 사용자별 권한 부여가 가능합니다.

2020년 KISA에서 발표한 “클라우드 취약점 점검 가이드”를 참고하여 보안 설정을 완료한 후 적절한 권한 부여를 통해 운영자, 개발자 분리가 충분히 가능합니다.