회원가입을 하면 원하는 문장을
저장할 수 있어요!
다음
국내 유명 IT 기업은 한국을 넘어 세계를 무대로 할 정도로 뛰어난 기술과 아이디어를 자랑합니다. 이들은 기업 블로그를 통해 이러한 정보를 공개하고 있습니다. 요즘IT는 기업들의 특색 있고 유익한 콘텐츠를 소개하는 시리즈를 준비했습니다. 이들은 어떻게 사고하고, 어떤 방식으로 일하는 걸까요?
회원가입을 하면 원하는 문장을
저장할 수 있어요!
다음
국내 유명 IT 기업은 한국을 넘어 세계를 무대로 할 정도로 뛰어난 기술과 아이디어를 자랑합니다. 이들은 기업 블로그를 통해 이러한 정보를 공개하고 있습니다. 요즘IT는 기업들의 특색 있고 유익한 콘텐츠를 소개하는 시리즈를 준비했습니다. 이들은 어떻게 사고하고, 어떤 방식으로 일하는 걸까요?
이번 글은 ‘전 세계 사람들에게 즐거움을 선사하자’는 비전을 바탕으로 게임을 만들고 있는 ‘넷마블’의 보안개발팀 이야기입니다. WAS 프로세스를 보호하기 위해 여섯 가지 WAS에서 root 이외의 계정으로 프로세스를 실행하는 방법과 프로세스 소유권을 바꾸는 방법에 대해 살펴보겠습니다.
| [여기보기]는 “여기서 보안의 기본을 챙기고 가자”의 약자로, 개발 과정에서 꼭 최소한으로 챙기면 좋은 보안 기초 설정을 앞으로 하나씩 공유할 예정입니다. 기초 내용이 주를 이루겠지만, 혹시라도 빼먹고 계신 것이 없는지 가끔 한 번씩 둘러봐 주세요. |
안녕하세요, 넷마블 보안실 보안개발팀 남현석입니다.
윈도우를 설치할 때 보통 관리자 권한을 갖는 계정을 생성합니다. 관리자 권한을 갖는 계정이면 프로그램의 모든 기능을 사용할 수 있고, PC에 문제가 발생했을 때 대처하기가 편하기 때문이죠.
단, 모든 프로그램을 무조건 권리자 권한으로 실행하지는 않습니다. 별도의 [관리자 권한으로 실행]이라는 메뉴를 이용해 실행합니다. 그럼 ‘사용자 계정 컨트롤’ 창이 열리면서 프로그램을 실행할 때 앱이나 디바이스를 변경할 수 있도록 허용할 것인지를 묻습니다(물론 관리자 권한을 갖는 계정이라면 [예]를 눌러 프로그램을 실행할 수 있습니다).
한 번 더 실행할 것임을 묻는 귀찮은 과정을 두는 이유는 시스템에 문제가 발생할 가능성을 조금이라도 줄이려는 것입니다. 집에서만 사용하거나, 나만 사용하는 PC의 권리자 권한조차 보안이 중요하다는 예이기도 합니다.
그럼 이 글의 주제인 웹 애플리케이션 서버(이하 WAS)는 어떨까요? WAS 관리자 권한은 시스템 취약점을 이용해 관리자 계정(리눅스의 root, 윈도우의 Administrator)이 탈취당하면 악의적인 사용자가 서버 전체의 제어 권한을 획득할 수 있습니다. 즉, 보안 문제가 발생할 뿐 아니라 서버를 사용할 수 없는 지경에 이를 수도 있죠. 이를 막는 기본적인 보안 조치가 궁금하다면 ‘[여기보기]’ 글 중, “뿌리 깊은 리눅스의 근본, 루트 계정을지켜라”를 읽어보면 좋겠습니다.
WAS 프로세스를 보호하려면 관리자 계정으로 구동하지 말아야 합니다. 이는 프로세스의 실행 계정이나 그룹이 root나 Administrator여서는 안 된다는 뜻입니다. 여기에서는 윈도우의 IIS(Internet Information Services), 아파치 HTTP 서버(Apache HTTP Server), 톰캣(Tomcat), 엔진엑스(NGINX), 스프링 부트(Spring Boot), Node.js의 여섯 가지 WAS에서 root 이외의 계정으로 프로세스를 실행하는 방법을 살펴봅니다. 또한 주요 프로세스의 소유권을 바꾸는 방법도 함께 살펴봅니다.
윈도우 IIS에는 컴퓨터 도메인을 관리하도록 기본 제공된 Administrator라는 계정이 있습니다. 실제 서비스를 동작시킬 별도의 계정(이하 서비스 계정)을 하나 만들고 Administrator 계정을 사용하면 안 되는 서비스는 새롭게 만든 서비스 계정으로 바꿔주면 됩니다.
‘실행’ 창에서 ‘compmgmt.msc’를 입력해 ‘컴퓨터 관리’를 실행합니다. 왼쪽 메뉴에서 [로컬 사용자 및 그룹] → [사용자]를 선택합니다. 그리고 위쪽 메뉴에서 [동작] → [새 사용자]를 선택해 관리자 이외로 IIS 서비스 동작에만 사용할 새 사용자(서비스 계정)를 추가합니다.
다음으로 ‘실행’ 창에서 ‘secpol.msc’를 입력해 ‘로컬 보안 정책’을 실행합니다. 그리고 [로컬 정책] → [사용자 권한 할당] → [서비스로 로그온]을 선택해 ‘서비스로 로그온 속성’ 창을 엽니다. [사용자 또는 그룹 추가]를 클릭한 후 ‘사용자, 컴퓨터, 서비스 계정 또는 그룹 선택’ 창에서 [고급]을 클릭하면 속성 창이 등장합니다. 창 오른쪽의 [지금 찾기]를 클릭하고 앞에서 추가한 서비스 계정을 선택합니다.
이렇게 관리자 이외로 IIS 서비스 동작에만 사용할 서비스 계정을 추가했습니다.
다음으로 ‘실행’ 창에서 ‘services.msc’를 입력해 ‘서비스’를 실행합니다. 그리고 [IIS Admin Service]의 속성 창을 열고 [로그온] 탭을 선택한 후 [계정 지정]을 활성화합니다. [계정 지정] 옆 [찾아보기]를 클릭한 후 앞 [서비스로 로그온] 부분을 참고해 서비스 계정과 내부 규칙 등에 따른 패스워드를 추가합니다.
참고로 [World Wide Web Publishing Service]에도 서비스 계정이 추가되지 않았다면 추가합니다.
마지막으로 IIS가 설치된 폴더(보통 C:\inetpub)의 속성 창을 열고 [보안] 탭을 선택합니다. [편집]을 클릭한 후 ‘사용 권한’ 창에서 [추가]를 클릭하고 앞 [서비스로 로그온] 부분을 참고해 서비스 계정을 추가합니다. 다음으로 추가한 서비스 계정을 선택한 후 [사용 권한] 항목에서 모든 권한을 선택해 사용 권한을 부여합니다.
서비스 계정에 모든 권한을 적용할 때 오류가 발생하면 다음 항목 참고해주세요.
리눅스에서 WAS 프로세스 보안 조치 방안의 기본은 프로세스(보통 자식 프로세스)가 root 계정으로 실행됐다면 서비스 계정으로 실행하도록 바꾸는 것입니다. 또한 설정 파일에 별도의 계정 설정이 있다면 서비스 계정으로 바꿉니다. 이에 맞춰서 아파치 HTTP 서버의 조치 방안을 살펴볼 것입니다.
‘ps -ef | grep httpd’ 혹은 ‘ps -ef | grep apache’ 명령을 실행해 현재 프로세스 실행 계정이 root인지 확인합니다. root 계정이라면 아파치 설정 파일을 열고 아파치 데몬의 ‘User’와 ‘Group’에 설정된 계정명과 그룹명을 서비스 계정과 서비스 그룹(서비스 계정을 포함할 root가 아닌 그룹)으로 바꿉니다.
3.7K
User [서비스계정명]
Group [서비스그룹명]
설치 방법별 아파치 설정 파일 경로는 아래를 참고해주세요.
‘[Apache2 Dir]/bin/httpd -k restart’ 혹은 ‘service apache restart’(CentOS는 ‘service httpd restart’) 명령을 실행한 후 다시 ‘ps -ef | grep httpd’ 혹은 ‘ps -ef | grep apache’ 명령을 실행해 자식 프로세스가 root 대신 아파치 설정 파일에서 수정한 서비스 계정으로 바뀌었는지 확인합니다.
톰캣은 패키지 관리 도구로 설치해 사용할 때와 소스 파일을 다운로드해 사용할 때의 프로세스 실행 계정 관리 방법이 조금 다릅니다. 패키지 관리 도구로 톰캣을 설치했을 때는 기본적으로 tomcat이라는 서비스 계정과 그룹을 생성하기 때문에 소유권을 바꿀 필요가 없습니다. 하지만 상황에 따라 소유권을 바꿀 경우도 있으므로 이를 살펴볼 것입니다.
소스 파일을 다운로드해 사용할 때는 WAS 프로세스 실행 계정이 root인지를 확인하지만, 실행과 관련된 파일의 소유권이 root인지도 확인합니다. 파일의 소유권이 root이라면 서비스 계정명과 그룹명으로 소유권을 바꿔주는 것이 좋습니다.
패키지 관리 도구
‘ps -ef | grep tomcat’ 명령을 실행해 현재 프로세스 계정이 root인지를 확인합니다. root라면 서비스 계정을 생성한 후 ‘service tomcat stop’ 등의 명령으로 톰캣 서비스를 중지합니다. 그리고 다음 명령을 실행해 서비스 계정을 ‘tomcat’ 그룹에 추가합니다.
$ usermod -aG tomcat 서비스계정명
이제 ‘/usr/lib/systemd/system/tomcat.service’을 열고 ‘[Service]’의 설정 항목 중 ‘User’를 서비스 계정명으로 바꿉니다.
[Service]
# 중간 생략
User=서비스계정명
Group=tomcat
# 이후 생략
수정을 완료하면 ‘systemctl daemon-reload’ 명령을 실행한 후 다시 ‘service tomcat start’ 등의 명령으로 톰캣 서비스를 실행합니다. ‘ps -ef | grep tomcat’ 명령을 실행해 프로세스 실행 계정이 서비스 계정으로 바뀌었는지 확인합니다.
소스 파일 다운로드
‘ps -ef | grep tomcat’ 명령을 실행해 현재 프로세스 계정이 root인지를 확인합니다. root라면 서비스 계정(여기에서는 iamironman)을 생성합니다. 그리고 [Tomcat Dir] 안 계정과 그룹에 root 이외의 서비스 계정을 사용할 수 있도록 권한을 부여(최소한 startup.sh와 shutdown.sh와 관련된 권한은 부여돼야 함)해야 합니다.
‘sudo su’ 명령으로 root 계정에 접근한 후 다음 명령을 실행해 새로운 서비스 그룹을 만들고 이를 확인합니다.
$ groupadd 서비스그룹명
$ tail /etc/group
다음 명령을 실행해 서비스 그룹에 여러분이 사용할 서비스 계정을 추가합니다.
$ usermod -aG 서비스그룹명 서비스계정명
이제 톰캣 [Tomcat Dir]의 전체 소유권을 변경합니다. 이어서 로그를 저장할 수 있도록 [Tomcat Dir]/logs 디렉터리의 권한에 쓰기 권한을 추가합니다.
$ chown -R iamironman:tomcat [Tomcat Dir]
$ chmod -R g+w [Tomcat Dir]/logs/
이제 root 계정에서 로그아웃한 후 서비스 계정으로 접속합니다. 그리고 ‘/[Tomcat Dir]/bin/startup.sh’ 명령을 실행해 톰캣을 실행할 수 있는지 확인합니다. 또한 정상적으로 실행됐다면 ‘/[Tomcat Dir]/bin/shutdown.sh’ 명령을 실행해 톰캣 실행을 중지시켜봅니다.
톰캣을 실행한 상태에서 ‘ps -ef | grep tomcat’ 명령을 실행하면 서비스 계정으로 프로세스가 실행됐음을 확인할 수 있습니다.
엔진엑스(NGINX) 프로세스 실행 계정 관리는 아파치 HTTP 서버와 거의 비슷합니다. 엔진엑스에서 제공하는 설정 파일에서 서비스 계정명과 그룹명을 설정하는 과정입니다.
‘ps -ef | grep nginx’ 명령을 실행해 자식 프로세스(nginx에서는 worker process로 표기)의 실행 계정이 root인지를 확인합니다. root라면 엔진엑스의 nginx.conf를 찾고 첫 행 ‘user’ 부분에 서비스 계정명과 그룹명을 설정합니다.
# 설정할 때 group 부분은 생략 가능(user값과 동일하게 적용)
user [서비스계정명] [서비스그룹명];
# 이후 생략
설치 방법별 엔진엑스 nginx.conf 경로는 아래를 참고해주세요.
‘[NGINX Dir]/nginx -s reload’ 혹은 ‘service nginx restart’ 명령을 실행한 후 ‘ps -ef | grep nginx’ 명령을 실행해 서비스 계정명과 그룹명을 확인합니다.
JDK 기반 프로젝트는 보통 WAS 기능이 포함된 프로젝트를 압축한 JAR이나 WAR 파일을 만들어 활용합니다. 스프링 부트 역시 JDK 기반 프로젝트이므로 JAR나 WAR 파일을 실행하는 프로세스가 WAS 프로세스입니다. 따라서 JAR나 WAR 파일의 소유권을 서비스 계정으로 변경하고 root가 아닌 서비스 계정으로 프로세스를 실행하는 것이 기본적인 관리 방법입니다. 여기에서는 그래들(Gradle)을 애용해서 만든 JAR 파일을 예를 들어 살펴봅니다.
리눅스 터미널에서는 보통 ‘./gradlew build’ 명령을 이용해 WAS를 실행하는 스프링 부트(Spring Boot) jar 파일을 생성합니다. 이때 root가 아닌 서비스 계정으로 jar 파일을 생성할 것을 권합니다. 그 이외에 이미 생성된 jar 파일이 있다면 파일 소유권이 root인지 확인합니다. root라면 서비스 계정 및 그룹으로 소유권을 바꿔줍니다(톰캣 부분의 서비스 계정 및 그룹 변경 과정을 참고).
Node.js와 Express 웹 프레임워크는 스프링 부트와 같이 js 파일을 실행하는 프로세스가 WAS 프로세스입니다. 따라서 프로세스 실행 계정 관리 방법이 스프링 부트와 거의 같습니다.
root가 아닌 서비스 계정으로 ‘node 파일명.js’ 혹은 ‘npm start’ 명령을 실행합니다.
또한 이미 생성된 프로젝트 디렉터리 혹은 최소 WAS 실행과 관련된 app.js나 index.js의 소유권을 확인합니다. root라면 서비스 계정 및 그룹으로 소유권(하위 디렉터리 포함)을 바꿔줍니다(톰캣 부분의 서비스 계정 및 그룹 변경 과정을 참고).
세상의 모든 연인이 다 행복하길 바라지만 연애하다 보면 헤어지는 게 나은 관계도 종종 생깁니다. 사실 WAS 프로세스와 root는 처음에 만났을 때는 행복하지만 결국은 헤어지는 연인 관계와도 같습니다. 게다가 연인 관계는 헤어질 때 종종 서로 줬던 선물을 버리거나 돌려주죠. 이런 부분이 바로 파일이나 디렉터리의 설정하는 소유권 이전이 아닐까 하는 생각입니다.
파일과 디렉터리의 소유권 관계가 궁금하다면 ‘[여기보기]’ 글 중, “파일과 디렉터리에는 정확한 소유권과 적당한 권한을 부여하라”를 읽어보면 좋겠습니다.
연애에 실패했지만 한결 성숙해져 새로운 연인과 잘 지내는 사람이 많습니다. WAS 프로세스는 서비스 계정이라는 새로운 연인을 만나 백년해로할 수 있을까요? 여하튼 아직도 root와 연애하는 WAS 프로세스가 있다면 오늘은 이들이 헤어져야 할지 고민해보면 어떨까요?
<원문>
좋아요
댓글
공유
공유
지금 회원가입하고,
요즘IT가 PICK한 뉴스레터를 받아보세요!
