수안이의 컴퓨터 연구실

세심한 어카운트 관리를 통해 위험을 줄이고 골치거리 줄이기

Cameron Laird
Vice president, Phaseit, Inc.
2002년 10월

보안은 크고 도전이되는 주제이지만 서버측 책임을 맡고있는 사람이라면 기본 단계를 알아야 한다. 이곳에서 사용자 어카운트를 깨끗하고 안전하게 유지하는 많은 방법들을 배워보자.
보안은 어렵다. 어디까지 확대 시켜야 하는지도 알기 힘들다.

컴퓨팅 보안의 모든 부분을 지켜가는 것은 도전이 되는 일이지만 실제로 배울 수 있는 방법들은 꾸준히 연구되어 왔다. 리눅스 서버로 작업하고있는 사람들에게 우선 권하고 싶은 것은 어카운트 관리이다.

사용자 중심으로
리눅스 관리와 프로그래밍을 집중해서 다룬 책들 대부분이 "사용자 관리" 또는 "어카운트 관리"를 포함하고 있다 .

그 당시 "사용(use)"은 "로그인(log in to)"을 의미했다. 어카운트 관리는 어카운트를 설정하기 위한 useradd, chsh 등의 명령어로 작업하는 것이였다.

그러한 시대는 오래전에 지나갔고 대부분의 서버에 대해 /etc/passwd를 줄일 것을 권고했다. 내가 생각하기에 이것은 실수였다. 하나의 이메일 서버가 수만 명의 사용자들을 위해 메일박스를 핸들 할 당시였다 하더라도 기존의 /etc/ 패스워드 관행은 실수였다.

/etc/passwd에 의존하는 것은 가능하다. 놀라운 워크로드를 핸들 할 정도로 충분히 패치와 트윅이 추가되었다. 하지만 그렇게 하지 말았어야 했다. 사용자 어카운트를 LDAP (lightweight directory access protocol)나 RDBMS (relational database management system) 같은 전용 데이터 저장소로 옮긴다면 안정성, 보안, 유지보수에 큰 혜택을 받게 된다. /etc/passwd는 진실로 로그인을 원하는 몇몇 개발자들과 관리자들에게만 제한해야 한다.

이 관행은 보안에 있어서 큰 이득을 안겨다준다. 왜냐하면 서비스(이메일, 웹 등등)의 듀티 사이클(duty cycle) 사용자들은 개발자의 듀티 싸이클과 완전히 다르기 때문이다. 새로운 서버에서는 /etc/passwd는 자주 바뀌면 안된다. 업데이트와 탬퍼링 여부를 모니터링 하는 것은 쉬운 일이다. 큰 서버를 실행하고 있다면 새롭고 종료된 이메일 어카운트 변경을 매일매일 겪어야 한다. 그들을 /etc/passwd가 제공하는 더 넓은 액세스에서 분리 할 필요가 있다.

상호적인 어카운트 데이터 저장소를 만드는 것이 심각하게 들리는가? 그렇다. 매우 큰 /etc/passwd를 만들어 적절히 작동시키기 위해 오랜 시간동안 많은 사람들이 노력했다. 자신만의 어카운트 인증을 코딩하기로 결정하고 sendmail 같은 전통적인 이메일 프로그램에 의존한다면 SMTP, POP3, IMAP4 서버용 변경을 작성해야 할 것이다.

그러한 장애물들은 일반적으로 일반 소프트웨어를 사용하는 개발자들에게 나타나는 경향이다. 내가 개인적으로 선호하는 것은 다른 사람들이 작성하고 내가 재사용 할 수 있는 솔루션이다. 산업용 서버와 한 가지 차이점은 커스터마이징해야 한다는 것이다. 예를 들어 특별한 메시지 디렉토리, 로깅 정보, 사용 어카운팅을 설정할 경우가 그 예이다.

정책 자동화
개발자 어카운트를 사용자 서비스와 분리시키는 것 만큼 중요한 것은 정책을 자동화하는 것이다. 개발자(/etc/passwd)와 엔드유저(e-mail, Web, database)를 위해 어카운트를 만들고 삭제하는 구체적이고 자세한 프로세스를 만들어라. 이것들을 실행파일(executable)로 캡쳐링하는 것은 좋지만 반드시 그래야 하는 것은 아니다. 중요한 것은 프로세스가 합당하고 명확해지도록 해야 한다. 일상적인 어카운트 생성과 삭제는 언제나 보안 허점을 남겨놓는다. 직원들, 고객 지원, 다른 부서와 프로세스를 검토하라. 대안을 간구하지 않는 한 이 일은 심각하다.

어카운트 자동화의 부수적인 이익 중 하나는 좀더 철저한 타당성 검사이다. 개발자가 다른 속성을 이용하여 어카운트를 설정하는 편리한 방법을 모른다면 그러한 설정들을 차별화 하는 애플리케이션을 실행할 수 없다.

지속적인 경계
보안을 잘 확립하기 위해서는 생각하지 못하는 부분까지도 경계를 늦추지 말아야한다.

어떻게 그와 같은 일이 가능한가? 불행히도 "똑똑해지기" 같은 추상적인 목표에 도달할 수 있는 몇 가지 체계적인 방법만 있을 뿐이다. 우리가 할 수 있는 구체적인 일이라면 RISKS digest와 숙련된 엔지니어링 리뷰를 공부하는 것이다.

RISKS는 Peter G. Neumann이 1985년 부터 발행하는 온라인 뉴스레터이다(참고자료). 이 글을 읽으면 특히 어떻게 잘못되어가는지에 대한 실질적인 생각을 할 수 있다. Neumann은 읽기쉽고 재미있게 글을 편집했다.

또 한가지, 여러분의 생각을 다른사람과 습관처럼 나누어야 한다. 이것은 생각보다 재미있고 생산적인 일이다. 특히 검사라는 것은 피어(peer) 리뷰를 조직화 할 수 있는 훌륭한 방법이다.

결론
아래 참고자료에는 서버 보안에 대한 주제를 다룬 글을 제공한다. 참고하기 바란다.

http://www.ibm.com/developerworks/kr/pr ··· red.html

http://www.ibm.com/developerworks/kr/pr ··· eyc.html

http://www.ibm.com/developerworks/kr/pr ··· l-sec%2F

http://catless.ncl.ac.uk/Risks

http://www.ibm.com/developerworks/kr/pr ··· y.com%2F

http://www.ibm.com/developerworks/kr/pr ··· sc2.html


http://www.awprofessional.com/catalog/product.asp?product_id={A13F0625-B030-4CD2-B5A8-B5977733E0A7}&session_id={13B2A3ED-6FF5-48B7-A60A-B195834120FE}

http://www.ibm.com/developerworks/kr/pr ··· s.org%2F

http://www.ibm.com/developerworks/kr/pr ··· igin%3Dl