한빛출판네트워크

제공 : 한빛 네트워크
저자 : Tom Adelstein
역자 : 이정목
원문 : Top 7 Things System Administrators Forget to Do

우리가 매일 하는 많은 일상적인 일 중에서 어떤 것들이 건망증이 있는 시스템 관리자가 가장 잘 저지르는 7가지에 포함될까? 먼저 여러분 스스로 질문에 대한 대답이 정성적인 것인지 아니면 정량적인 것인지 의문을 가질지도 모르겠다. 그것에 대해서 잠시 생각해보자.

여러분은 무언가를 잊어버리는 횟수를 알 수 있었을 것이다. 그랬다면 여러분은 알람 시계를 설정하는 것을 잊어버리거나 짝이 맞지 않는 양말을 신고 일하러 간다거나 하는 것들의 목록을 만들 수 있을 것이다. 우리는 회사를 막 떠난 직원의 VPN을 통한 원격 접속을 끊는 것을 잊어버리는, 다소 위험한 것도 목록에 필요할 것이다.

이 기사를 쓰면서, 나는 내가 공학자의 사이먼 코웰이라고 느꼈지만 사실은 그 반대이다. 여러가지 의미있는 후보들 중에서 나는 폴라 압둘은 제안하지 못했을 7개 만을 가려낼 수 있었다. 내 주관적인 관점 외에 다른 엔지니어들을 상담하기로 결심했다. 상담을 했던 사람들은 관리자들은 중요한 것들을 잊어버린다라는 것은 확실하다고 생각했다.

나는 왜 그들이 중요한 일들을 잊어버리는지 여러 가지 이유를 댈 수 있었다. 이러한 이유들 중에는 보통 둘 이상의 사람을 필요로 하는 일을 한다거나, 하드웨어에 대한 고장수리 서비스를 제공해야 하는 것, 결근한 헬프데스크 직원을 대신한다거나 사전 판매 활동에 참여한다거나 하는 것들이 포함된다. 여하튼 아래는 시스템 관리자가 가장 잘 잊어버리는 7가지를 나열한 것이다.

1. 이전 사용자의 계정 삭제를 잊어버리는 것

한 주에 같은 도시에서 IBM, Novell, HP가 세미나를 개최할 때 여러분은 그들의 Identity Management System이 왜 필요한지 대해서는 이해한다. 이름을 거론하지는 않겠지만 포춘지 선정 50대 기업 중 몇몇은 5년 동안 이전 사용자 계정을 삭제하는 것을 잊어버렸다. 이러한 이전 직원의 계정은 인적 자원 및 급여 데이터베이스, 컴퓨터 디렉터리, SID, SAM, AD의 주소록에 저장되어 있었다. 벤더들은 여러분 회사에 시스템 관리자가 충분히 있지 않고, 또한 여러분이 그러한 시스템 관리자들을 충분할 만큼 확보할 수 없을 것이므로 Tivoli, eDirectory, OpenView와 같은 것들이 필요하다고 말할 것이다.

직장에 시스템 관리자가 충분한지 실제로 누가 알겠는가? 내가 수행한 조사에 따르면 시스템 관리자들은 그들의 업무 부담과 기획 시간의 부족, 작업 우선순위를 매길 필요가 있음에 대해 불만을 토로했다. 나는 작업 목록을 유지하는지 여러 사람들에게 물어봤는데 거의 하지 않는다고 답했다. 조사를 한 엔지니어 중 약 90%는 그들의 일일 스케줄을 그들의 머리 속에 넣은 채로 일을 시작한다. 나는 그것을 태만한 것으로 조사결과에 넣었다.

나는 야채 상점에 목록 없이는 거의 가지 않는다. 왜냐하면 내가 원하는 것을 기억해낼 수 없기 때문이다. 세탁용 세제나 비타민과 같은 알기 쉬운 것들을 잊어버린다. 사야 할 야채 목록에서 15개의 품목을 기억할 수 없다면 회사에서 해야 할 것들을 기억해 내리라는 것을 어떻게 기대할 것인가? 나는 목록 없이는 일을 잘 해내지 못한다.

사람들이 떠나고 나면 문을 닫아야 한다. 또한 따라야 할 체크리스트와 누가 남아있는지 알아낼 방법이 필요하다. 여러분은 이전 사용자 계정이 활성화된 채로 남아있는 것을 정당화할 수는 없다. 몇 가지 기억해야 하는 것에는 사용자의 비밀번호를 사용할 수 없도록 만드는 것이 포함된다. 나는 이전 사용자의 디렉터리를 유지하고 싶은데, 왜냐하면 다른 누군가가 이전 사용자의 자리를 대신할 수도 있기 때문이다. 보통 나는 그 디렉터리를 다른 곳으로 이동시키고 이름을 바꾼다. 종종 우리는 이전 사용자 디렉터리의 내용을 그대로 유지하기를 원한다.

여러분 조직의 IT 정책에 의해 여러분은 취해야 할 행동 목록을 작성하고자 할 것이다. 여러분은 단순히 사용자의 비밀번호를 변경하는 것 뿐만 아니라 더 많은 일을 해야 한다는 것을 기억하라. 만약 이 사용자가 루트 권한을 가졌었다면, 여러분은 트로이 목마 시스템 바이너리에서부터 알려지지 않은 커널 모듈에 이르기까지 무언가를 발견할 수 있을지도 모른다. 이러한 사실을 명심해야만 다음 주제인 루트킷으로 옮겨갈 수 있다.

2. 주기적으로 루트킷 검색을 잊어버리는 것

루트킷은 인가되지 않은 사용자가 수퍼유저나 도메인 관리자 계정에 대한 접근권한을 얻도록 해준다. 동일한 소프트웨어는 침입자가 그들의 침입경로를 숨겨 시스템상의 파일 등을 훔치거나 제거하도록 할 수 있다. 루트킷은 누군가가 하이잭 당한 컴퓨터에 대해 지속적으로 접근할 수 있도록 해준다. 프로그래머는 어떠한 운영체제의 루트킷도 작성할 수 있다. 만약 여러분이 40,000개의 고객 파일을 유실했다는 회사에 관해 들어본 적이 있다면 보통 그것이 루트킷 때문이라는 것을 알게 될 것이다.

사용자 레벨의 루트킷은 탐지와 제거가 용이하다. 이 레벨에서는 루트킷 소프트웨어는 하나 이상의 인가된 사용자의 애플리케이션을 변경된 프로그램으로 대체한다. 유닉스 스타일의 시스템이나 새로나온 전용 시스템(proprietary system)에서는 여러분이 커널을 신뢰할 경우 사용자 레벨의 루트킷을 탐지해낼 수 있다. AIDE와 Tripwire와 같은 프로그램들이 이러한 유형의 루트킷을 탐지해낼 수 있다.

커널 레벨의 루트킷은 찾아내기가 쉽지 않은데, 왜냐하면 루트킷이 존재하고 있는 커널을 신뢰할 수 없기 때문이다. 우리는 커널 레벨의 루트킷이 침입자의 침입경로를 숨기기 위해 로그를 삭제하고 그것을 시스템 호출로 대체하는 것을 본 적이 있다. 커널 레벨의 루트킷은 리눅스 커널 모듈(LKM; Linux Kernel Module)이나 윈도 서버의 서비스로서 존재할 수 있다. 최근에 나는 악성 서비스(rogue service)가 테스트 환경의 윈도 2003 R2 서버상에서 작동하고 있는 것을 발견했다. LKM 루트킷의 몇 가지 예를 들자면 Afhrm과 Synapsis이 있다. 이전의 윈도 커널 모드 트로이 목마에는 Slanret, IERK, Backdoor-AL과 같은 것들이 있다.

여러분이 커널을 신뢰할 수 없으므로 보안 전문가들은 영향을 받지 않는 다른 머신에 패킷 스니퍼를 설치한다. 전문가들은 그 머신에서 보내고 받는 패킷 중 루트킷이 존재하리라 예상하는 것들을 살펴본다. 커널 레벨의 루트킷을 탐지하는 또 다른 방법은 라이브 CD로 부팅되는 것과 관련이 있다. 라이브 CD는 여러분이 신뢰할 수 있는 커널을 포함하고 있으며 따라서 여러분이 드라이브를 조사할 수 있도록 해줄 것이다.

머신상의 변경사항들을 살펴보는 파일 무결성 검사를 이용하여 여러분의 시스템을 모니터링 하라. 최근에 설치된 OS 이미지나 추가된 소프트웨어에 대한 핑거 프린트(fingerprint)를 만들어라. 핑거 프린트는 암호화 기법을 이용하여 파일에 들어있는 모든 데이터에 대한 해시를 만든다. 여러분이 한번 해시를 만들어 놓기만 하면 여러분은 저장되어 있는 해시 값과 실행중인 해시 값을 비교할 수 있다. 그렇게 되면 여러분은 변경사항을 알아내어 누군가가 여러분의 시스템에 로그 프로그램을 집어 넣었는지 확인할 수 있게 된다.

3. Trouble Ticket Tracking System을 사용하는 것을 잊어버리는 것

여러분은 Trouble Ticketing System에 관한 RFC가 있다는 것을 알고 있었는가? NOC Internal Integrated Trouble Ticket System Functional Specification Wish List에 관한 RFC인 RFC 1297은 IETF(Internet Engineering Task Force) 스펙이다. RFC의 작성자는 trouble ticket을 환자의 병원 차트와 비교하고 있다. 둘 모두 어떤 문제를 정의하며, 매번 다른 시간대에 일하는 사람들과 해결방법을 조정하는 것을 도와주기 때문이다.

초기에 내부 클라이언트는 지원 시스템으로 이동하는 티켓을 만든다. 티켓은 이슈를 식별하고 문제를 해결하는데 필요한 기술과 전문적인 지식을 결정하는 데 도움을 준다. 그 티켓에 할당된 한 명 혹은 여러 명의 사람들이 그 이슈를 해결할 때까지 그 티켓은 열려진 채로 유지된다.

trouble ticket이나 trouble report는 전문가에 의해 수행된 액션들을 기록하며 그 문제의 해결 진행상황에 관하여 케이스 관리자(case manager)에게 보고한다. Trouble ticketing system의 유래를 추적하는 과정에서 나는 그것이 종이 기반의 리포팅 시스템(paper-based reporting system)과 같은 제조업에서 유래했음을 알게 되었다.

오늘날 거의 모든 trouble tracking system들은 웹 기반 애플리케이션이다. 만약 trouble tracking system을 사용하는 것을 잊어버리게 되면 아래에서 설명하는 유형의 문제에 봉착하게될 것이다.

4. 기술 문서 준비와 지식기반(knowledge base) 작성을 잊어버리는 것

지난 2월에 나는 리눅스 시스템 관리자 일자리를 구하기 위해 면접을 보았다. 그 회사는 세계적인 VoIP 네트워크에 사용되는 미션 크리티컬한 애플리케이션을 실행 중인 30개의 리눅스 박스(linux box)를 보유하고 있었다. 내가 기술 문서를 요청하기 전까지는 그 일자리를 얻는데 근접했다. 그 회사를 그만 두려는 시스템 관리자는 코드가 있는데, 뭐가 더 필요하느냐고 나에게 반문했다. 나는 그 회사의 경영이사에게 그 회사의 문서화 상태를 알아본 후에 나에게 일자리를 제안하는 것을 자제해 달라고 요청했다.

나는 내가 궁극적으로 다시 보게 될 문제들에 대한 해결책을 몇 번이나 잊어버렸는지 궁금하다. 아마 여러분은 해결책을 바로 써서 정리할 수 있을 것이라고 깨닫게 되면 어리석어 보일 것이다. 그렇게 하는 대신 우리는 필요로 하는 해답을 알아내기 위한 노력을 똑같이 되풀이하게 될 것이다.

2001년 11월 나는 지원 스탭에 85일짜리 백로그가 있다는 것을 알게 되었다. 그 이후로 지원시스템은 단순히 고객 서비스를 요청하는 모든 전자메일을 삭제하였다. 나는 그 이슈를 시스템 관리자와 개발 팀에게 알려주었고 그 상황을 위기상황으로 선언하였다. 또한 시스템 관리자가 고객 서비스 부서를 지원할 책임이 있다는 것도 알게 되었다. 프로그래밍 팀은 모든 개발을 중지하고 이러한 큰 문제를 신속하게 해결할 수 있는 해결책을 찾아보기 시작했다. 우리는 Best Practical Solutions LLC의 요청 추적기(RT; Request Tracker)를 알게 되었고 그 시스템을 구현하였다. 열흘이 지나기 전에 우리는 목록상의 모든 항목들을 제거하였고, RT를 새로 고용한 고객 서비스 대표에게 되돌려주었다.

우리가 ticket tracking system에 대한 해결방법을 찾는 동안 기존의 모든 지식기반이 회사에 있는 RT와도 잘 맞지 않음을 알게 되었다. 우리는 교육을 받은 작성자도 우리가 필요한 내용을 작성하게 할 수는 없었다. 그 당시 Practical Solutions는 사용할 수 있는 RTFM 지식 관리 시스템을 갖추고 있지 않았다.

해결방법은 닫힌 trouble ticket과 웹 기반 FAQ 소프트웨어 시스템간의 연동을 자동화하는 것과 관련되어 있었다. 고객 서비스 위기상황이 지난 후 우리는 기술적 이슈를 다시는 무시하게 할 수 없었다.

5. 플래시 메모리 드라이브의 위험성을 잊어버리는 것

USB 플래시 드라이브는 크기가 큰 파일을 동료나 클라이언트의 멀리 떨어진 사무실에 전송하고, 호환성에 관해 신경 쓸 필요 없이 그 데이터에 접근할 수 있다. 여러분은 집에서 업무를 보거나 랩탑 없이도 그 데이터를 이동시킬 수 있다. CD-R 디스크와는 달리 여러분은 바로 플래시 드라이브상의 문서나 데이터를 편집할 수 있다. 파일 백업 역시 가능하다.

그렇지만 플래시 메모리는 시스템 관리자의 최악의 악몽이 될 수 있다. 바이러스를 집에서 옮겨올 수 있으며, 직원들은 회사 소프트웨어 패키지의 "홈 카피(home copy)"를 만들거나, 최악의 경우 회사 기밀을 훔치는 데 플래시 메모리를 사용할 수도 있다(예를 들어, 거래 기밀이나 고객 목록과 같은 기밀 데이터를 훔치는데)

영국의 기업 IT 관리자를 대상으로 행해진 조사는 다음의 사실들을 보여준다:
업무의 84퍼센트는 직원들이 네트워크상에서 이동식 미디어를 사용하는 것을 방지하는 보안 정책을 갖고 있지 않다고 답했다. 응답자의 과반수가 직원들이 중요한 회사 데이터에 대해 불필요한 위험을 무릅쓰고 있다고 믿고 있다.

5명 중 2명은 이동식 미디어가 민감한 회사 정보를 훔치는데 사용되었는지는 모른다고 인정했다. 기업 중 85 퍼센트는 직원들이 회사에서 이동식 데이터기기를 사용하여 사무실과 집 사이에서 데이터를 옮기고 있다고 말했다.

6. 부분 루트 접근권한에 대한 관리를 잊어버리는 것

수많은 관리자들은 유닉스 기반 시스템상에서 sudo를 사용하거나 윈도상에서 "run as"를 사용하는 것이 모든 루트 접근권한을 주지 않고 시스템 관리책임의 일부만을 비관리자에게 위임하도록 해주는 데 있어 만병통치약이라고 믿고 있다. sudo는 사용자가 현재 비밀번호를 입력하고 난 다음에는 setuid 루트 바이너리를 사용하여 인가된 사용자를 대신하여 명령어를 실행한다.

이렇게 하면 루트계정의 비밀번호를 입력하지 않고도 여러분에게 제한된 루트 접근권한을 주기는 하지만 실제로는 모든 sudo 사용자를 완전히 신뢰할 수 있을 경우에만 유용한 방법이다. 조직이 커감에 따라 관리자들은 종종 누가 부분 루트 접근권한을 가졌는지 잊어버릴 것이다. 임원, 경영부서, 사용자의 변화 및 자원 부족은 일반 사용자가 알려진 익스플로잇(exploit)을 가진 프로그램에 접근권한을 가질 수 있도록 해준다. 그러한 연유로 변화하는 비즈니스 환경에서 여러분은 sudo 사용자 그룹을 제어할 수 없게 될 수도 있다. 이 문제에 대한 해결책은 sudo 사용자들에 대한 관리를 집중화시키는 것과 관련되어 있다.

7. 친절함을 잊어버리는 것

나는 이러한 일이 몇 번이나 일어나는지 궁금하다. 한달 전, 사무실의 한 아가씨가 커다란 회의용 테이블을 옮기려고 했다. CTO와 나는 용감하게 그녀를 도우려고 했지만 우리는 실패했다. 우리가 옮기기에 그 테이블은 너무 무거웠다. CTO는 주위를 둘러보고 두 명의 IT 부서 사람에게 도움을 청했다. 여러분은 그들이 상사를 기쁘게 하려고 흔쾌히 응하리라 생각할 수도 있다. 두 IT 부서 사람은 우리를 노려보았다. 그 아가씨와 나는 동시에 말했다. "그 사람들에게 부탁하지 말아요".

나는 회사에 막 들어왔기 때문에 내가 들었던 이야기를 믿을 수가 없었다. 나는 화가 나서 내 직속 상관에게 IT 부서에서 온 사람들은 누군가가 도움을 요청할 때 노려보는지 물어보았다. 그는 긍정적인 어조로 나에게 반문했다. "IT 사람들이 다 그렇지는 않잖아요?"

나는 바쁜 관리자들이 보여주는 삐뚤어진 태도를 이해한다. 나는 여러 번에 걸쳐 주말에 밤을 샜었다. 운 좋게도 내가 헬프 데스크와 콜 센터 교육과정을 받는 초기에는 몇 사람이 나에게 몇 시간을 자던지 간에 미소짓고 도움을 주고자 하는 태도가 필요함을 가르쳐 주었다. 친절함과 흥정에 능한 것은 직업 윤리의 표상이다.

이제 문제를 일으키는 사람들이 주위에 있다고 말했다. 그래서 나는 기술 지원 직원에 대한 일반 직무 설명서를 작성했다. 나는 Monster와 Dice job 게시판에 나열되어 있는 몇 가지 직무 요건을 함께 집어넣었다. 그리고 나서 그것을 상관에게 보여주었고 그것을 읽어보도록 했다. 그 후 얼마 되지 않아 나는 문이 닫혀져 있는 것을 보았고 컴퓨터 부품 같은 것이 벽에 던져지는 듯한 소리를 들었다. IT 부서 사람들이 사무실에서 나와 나를 죽이려 들었다. 그들은 데이터 센터로 들어가서 일주일 동안 나오지 않았다. 그런데 그 사람들이 데이터 센터에서 나올 때 한가지 웃긴 일이 일어났다. 그 사람들은 가라앉아 있었고 정중하게 사과했다. 그들이 친절해진 것이다.

나는 회사의 다른 부서 사람들에게 그 부서의 IT 직원들이 얼간이처럼 행동했는지 물어보기 시작했다. 나는 우리가 경영자 교육이 필요한 시스템 관리자들을 모두 그렇게 바꾸지는 못했음을 알게 되었다. 몇 군데에서 바뀐다고 해서는 아무것도 변하지 않을 것이다. 이런 일이 세상에는 많이 일어나고 있다.

만약 여러분이 경영부서의 지원을 받고자 한다면 오늘 여러분이 화나게 한 사용자가 이사회를 뒤집어엎을 수 있다는 것을 기억하라. 그러한 가능성과는 상관없이 시스템 관리자들은 항상 클라이언트가 내부에 있고 일자리를 계속 유지하고자 한다면 여러분의 클라이언트에게 잘 해줘야 한다는 것을 기억해야 한다.

최종 결론

시스템 관리자가 정말로 게을러서 잊어버리거나 업무 압박 때문에 업무를 모두 하지 못할까? 후자가 사실이라면 해야 할 것들 중 조금 덜 중요한 것들은 하지 않아도 된다. 내 경험상 그렇게 많은 일을 하는 사람은 거의 없다. 만약 여러분이 기본적으로 하루에 15시간 동안 일을 해야 한다면 관리부서는 IT 부서에 대한 보상을 재평가해야 할 필요가 있다. 사실이 그렇다.

---

저자 Tom Adelstein는 대규모의 국제적인 출판업 회사에서 기술 분석 기고자로 일하고 있다. 그는 1985년에 우연히 기고한 이후로 많은 양의 글을 써오고 있다.