Security

공유 계정 암호 관리의 이해

Chris Stoneff

한 눈에 보기:

• 공유되고 권한이 부여된 계정 암호의 위험성
• 암호가 저장되는 방법
• 공유 암호 관리 및 보안
• 규정 준수

목차

문제의 이해
길수록 강력해지는 암호
도메인에서의 위험성
다양한 변명들
감사관이 원하는 것
자동화된 방법
고려할 내용

관리자가 반드시 해결해야 하는 일반적인 문제 중 하나로

기본 제공 관리자이나 루트 계정, 파이어콜(firecall) 계정 또는 심지어 프로세스 계정과 같은 공유되고 권한이 부여된 계정의 암호를 주기적으로 변경하는 것이 있으며 이러한 문제의 중요성은 날로 높아지고 있습니다. 정의를 내리자면 기본 제공 관리자 또는 루트 계정은 모든 Windows®, Linux 및 UNIX 버전에서 제공되는 계정이며 항상 동일한 SID(보안 식별자)나 UID(사용자 식별자)를 가집니다. 파이어콜 계정은 보안 시스템에 대한 응급 액세스를 원활하게 수행하도록 지원하기 위해 만드는 다른 계정입니다. 이러한 파이어콜 또는 관리자 계정은 가끔 문제가 발생하는 경우 권한이 없는 사용자가 핵심 시스템에 대한 액세스를 얻는 데 사용됩니다. 마지막으로 프로세스 계정은 서비스, 작업, COM+ 응용 프로그램, 그리고 로그인이 필요한 스크립트 및 다른 이진 파일과 같은 포함된 항목을 실행하는 데 사용되는 계정입니다.

지금은 설치 스크립트나 이미지를 사용하여 시스템을 배포하는 경우가 많습니다. 게다가 모든 워크스테이션이나 서버의 관리자 계정 이름이 같고 시스템을 처음 배포한 이후로 변경하지 않은 동일한 8문자 암호가 설정되어 있는 경우가 많습니다. 여기에서 문제는 동일한 하나의 암호가 사용된다는 것입니다.

관리자는 모범 사례를 따르거나 SOX(Sarbanes-Oxley), PCI(Payment Card Industry) 또는 HIPAA(Health Insurance Portability and Accountability Act)에서 요구되는 규정 준수 요구 사항을 충족하기 위해 암호를 변경합니다. 이 밖에도 이러한 암호를 알고 있는 이전 관리자나 기술자가 퇴사하거나 보안 위반이 알려질 우려가 있거나 또는 신용 카드 가맹점 자격을 잃을 우려 때문에 관리자가 나서서 암호를 변경하기도 합니다. 이러한 요인에도 불구하고 결국 회사 자체 및 회사에서 보호해야 하는 데이터에 대한 단순한 보안을 위해 이러한 암호를 변경하는 일은 관리자의 몫입니다.

문제의 이해

이러한 계정 및 해당 암호를 처리할 때 이해해야 할 몇 가지 요인이 있습니다.

1. 암호가 오래될수록 암호의 보안성은 저하됩니다.
2. 일반적으로 암호가 길수록 해독하기 어렵습니다.
3. 컴퓨터가 도메인에 속해 있더라도 인증 방법이 달라지지는 않습니다. 모든 도메인에는 작업 그룹의 핵심이 있습니다.

"암호가 오래될수록 암호의 보안성은 저하됩니다."라는 내용에는 오해의 소지가 있습니다. 이 문장의 실질적인 의미는 컴퓨터에 칩입하려는 의지가 있다면 정말로 필요한 것은 시간뿐이라는 것입니다. 암호를 해독하는 데 시간이 얼마나 걸리는지 묻는 질문에 대한 명확한 대답은 일반적으로 없다고 할 수 있지만 특정 시스템에 해당하는 답을 알아내는 데 도움이 되는 몇 가지 힌트가 있습니다.

• 암호를 아는 사람이 몇 명입니까?
• 이들이 아직 회사에서 일하고 있습니까?
• 계정 암호를 아는 사람이 퇴사했다면 이들이 퇴사할 때 우호적이었습니까?
• 플로피 디스크, CD 또는 DVD 드라이브, 네트워크로부터의 부팅을 금지하고 있습니까?
• 컴퓨터의 사용자가 로컬 관리자이기도 합니까?
• 사용자의 모든 시스템이 해당 시스템의 권한이 부여된 계정에 완전히 같은 암호를 사용하고 있습니까?

목록 맨 위의 항목부터 시작하면, 비밀을 아는 사람이 많아지면 그것은 더 이상 비밀이 아니라고 할 수 있습니다. 필자가 예전에 근무하던 한 회사에서는 관리자가 편의를 위해서 공유 암호를 동일하게 설정하고, 다른 사용자가 요청할 때 자신이 암호를 대신 입력해 주기보다는 인턴을 포함한 모든 IT 직원에게 암호를 알려 주었습니다. 시간이 지나면서 이 회사에서는 승인되지 않는 다양한 설정을 가진 시스템이 생겼으며 일반적인 네트워크 사용자가 이러한 계정에 로그인하는 경우도 많아졌습니다.

암호를 아는 사람이 모두 회사에서 근무하고 있고 회사에 만족하는 성실한 직원이라면 이 액세스 위험은 다소 완화됩니다. 그러나 불만을 품은 악의적인 사용자가 있을 수도 있습니다. 이러한 사용자 중 누구라도 좋지 않은 감정을 가지고 회사를 떠난다면 추적할 수 없는 계정으로 여러분의 네트워크에 칩입할 수 있는 악의적 요소가 생기는 것입니다.

하드 디스크 외의 다른 방법을 통한 부팅을 금지하지 않으면 컴퓨터의 파일 시스템에서 직접 읽기를 수행하고 컴퓨터의 보안 저장소에 액세스할 수 있는 Windows PE나 다양한 Linux 시스템과 같은 승인되지 않은 이미지를 사용하여 부팅할 수 있도록 허용하는 것이나 다름이 없습니다. 침해의 많은 부분이 내부 요소에서 발생한다는 점을 알아 두십시오. 모든 직원과 인턴이 회사에서 근무하고 있더라도 암호와 시스템이 안전하다는 보장은 없습니다.

필자는 이전에 근무하던 회사의 네트워크에 거리낌 없이 로그온하는 사람들을 자주 보았습니다. 시스템 암호를 변경하지 않는 잘못된 정책을 지적한다는 긍정적인 측면도 생각할 수 있긴 하지만 이들이 악의를 가지고 있을 경우 가할 수 있는 피해를 생각하면 가볍게 볼 수 없는 문제이기도 합니다.

사용자가 DVD나 네트워크를 통해 부팅하는 것을 금지하지 않으면 사용자가 하는 일을 감사할 수 없습니다. 즉, 사용자가 Linux 부트 디스크나 네트워크 이미지를 사용하여 파일 시스템에 직접 액세스할 수 있게 됩니다. 시스템에서 권한이 부여된 계정에 같은 사용자 이름과 암호를 사용한다면 심각한 문제를 자청해서 불러들이는 것이나 마찬가지입니다. 이 부분에 대해서는 뒤에서 다시 설명하겠습니다.

암호 사용 기간과 길이는 암호를 해독하는 데 사용되는 방법과 관련이 있습니다. 무차별 공격으로 암호를 알아내는 경우에는 무엇보다 시간이 중요한 요소입니다. 암호 사용 기간이 길어질수록 크랙커가 암호를 해독에 사용할 수 있는 시간대도 길어집니다.

비슷하게 암호가 길어질수록 문자 조합이 기하급수적으로 늘어나므로 암호를 해독하는 데 더 많은 시간이 소요됩니다. 따라서 암호의 길이를 7자 미만으로 할 것인지, 8-14자로 할 것인지, 또는 15자 이상으로 할 것인지 고려하는 것이 중요합니다. Windows를 사용하고 있고 암호가 15자 미만이라면 시스템 구성 과정의 일부나 그룹 정책에 따라 LM(LAN Manager) 해시를 비활성화했는지도 확인해야 합니다.

암호의 길이가 어떻게 다른 부분에까지 영향을 주는 것일까요? Windows의 경우에는 그 이유가 간단합니다. Microsoft 해싱 프로세스의 역사는 생략하고 본론으로 넘어가면, Microsoft는 암호를 위한 두 가지 유형의 해시로 LM 해시와 MD4(메시지 다이제스트 4) 해시를 구현합니다. Microsoft는 기본적으로 LM 해시를 사용하는데 명시적으로 이러한 해시 저장을 비활성화하지 않으면 14자까지의 모든 암호에 대한 해시를 저장합니다. 이러한 암호는 그림 1에 나와 있는 것처럼 처음 부분과 나중 부분이 모두 7문자로 구성된 두 개의 7문자 값으로 나누어집니다.

그림 1 샘플 해시 테이블

즉, 7문자 길이 암호는 단일 LM 해시에 보관됩니다. Microsoft에서는 오랫동안 암호에 최소한 8문자를 사용하도록 권장해 왔습니다. 이렇게 하면 8번째 문자 때문에 암호를 두 개의 LM 해시 값으로 나누어야 하기 때문입니다.

중요한 것은 LM 해시가 널리 파악되고 있으며 매우 쉽게 이를 우회할 수 있다는 사실입니다. 현재 솔루션에서 LM 해시를 사용하는 것은 단지 Windows NT® 4.0과 같은 이전 버전에 대한 호환성을 유지하기 위해서 입니다.

이제는 15문자 이상의 암호를 사용해야 하며 아예 LM 해시를 생성하지 않도록 이보다 긴 암호를 사용하는 것도 고려할 수 있습니다. 여러분의 환경에서 15문자 암호를 요구하는 데 무리가 있는 경우에는 이미지 생성 프로세스(로컬 정책 사용)와 Active Directory® 그룹 정책에서 모두 LM 해시 저장을 비활성화해야 합니다.

이 정책은 Computer Configuration(컴퓨터 구성)\Windows Settings(Windows 설정)\Security Settings(보안 설정)\Local Policies(로컬 정책)\Security Options(보안 옵션)에 있습니다. "네트워크 보안: 다음 암호 변경 시 LAN Manager 해시 값 저장 안 함" 정책을 사용으로 설정하면 됩니다.

대/소문자와 숫자 또는 특수 문자를 함께 사용하도록 요구하는 것도 좋은 정책이지만 이보다 15문자 이상을 사용하도록 요구하는 것이 더 좋은 정책입니다.

길수록 강력해지는 암호

컴퓨터에 침입하기 위한 최근의 방법 중 하나인 레인보우 테이블은 LM 해시를 사용합니다. 그러나 암호가 길면 레인보우 테이블의 효과가 감소합니다.

보안을 담당하는 관리자 중에서 레인보우 테이블을 잘 모르거나 혹은 아예 모르는 사람들이 많다는 사실은 상당히 놀라운 일입니다. 다양한 알고리즘을 처리하기 위한 레인보우 테이블을 만드는 여러 가지 방법이 있지만 이러한 테이블은 기본적으로 0-14 문자의 모든 LM 해시를 포함하는 미리 계산된 목록입니다.

레인보우 테이블을 사용하려면 공격자가 먼저 LM 해시를 입수해야 합니다. 앞에서 설명한 대로 CD나 DVD를 통해서 시스템을 부팅할 수 있거나 사용자가 로컬 관리자인 경우에는 pwdump와 같은 무료 도구를 사용하여 간단하게 LM 해시를 추출할 수 있습니다. 그런 다음 레인보우 테이블을 사용하여 해시를 검색하여 암호를 알아낼 수 있습니다.

여러분의 호기심을 충족시키기 위해서 필자는 시스템의 기본 제공 관리 계정 암호를 설정해 보았습니다. 암호의 길이는 14문자로 설정하고 다양한 대/소문자와 특수 문자, 숫자를 모두 포함하도록 했습니다. 그런 다음 인터넷에서 무료로 레인보우 테이블을 다운로드하고 필자의 시스템에서 모든 계정에 대한 암호 해시를 추출한 다음 관리자의 암호를 알아내는 데 걸린 시간은 2분도 되지 않았습니다.

실제로 처음 LM 해시를 해독한 다음 이어서 나중 해시를 해독하고 이렇게 다시 암호를 얻는 과정을 직접 보면 멋있다는 생각까지 듭니다. 다시 정리하자면, 앞서 설명한 대로 정책을 통해 LM 해시를 비활성화했다면 이러한 공격 방향은 아예 차단되거나 크게 제한됩니다.

도메인에서의 위험성

도메인이 문제를 해결해 주지는 않습니다. 도메인 안에 있는 컴퓨터도 여전히 같은 방법으로 인증해야 합니다. 그리고 앞에서 이야기했듯이 모든 도메인에는 작업 그룹의 핵심이 있습니다. 항상 명백하게 이를 확인할 수 있는 것은 아닙니다. 필자는 이 주제로 많은 대화를 나누었는데 그때마다 관리자들에게 시스템에 액세스하는 데 필요한 사용자 이름과 암호라는 두 가지 요소를 강조하게 됩니다. 작업 그룹에서 Windows가 어떻게 작동하는지에 대해서 먼저 살펴보아야 할 것 같습니다.

시스템에 액세스하려면 원격 시스템에 대한 사용자 이름과 암호를 제공해야 합니다. Windows는 통합된 인증을 사용하여 여러분 대신 이 작업을 수행합니다. 이것은 다른 Windows 시스템에 액세스하는 경우 Windows는 현재 로그인한 사용자 이름과 암호를 사용한다는 것을 의미합니다. 다른 Windows 시스템에 액세스하는 경우 원격 시스템에 동일한 사용자 이름과 암호가 있으면 사용자 이름과 암호를 묻는 메시지를 표시하지 않습니다.

이러한 기능을 통과 인증이라고도 합니다. 이 프로세는 도메인 간은 물론 작업 그룹에서도 작동합니다. 최악의 경우에는 시스템에서 사용자 이름과 암호를 묻지만 간단하게 사용자의 로그온 정보를 다시 입력하면 됩니다.

워크스테이션이나 서버를 도메인에 등록하여 Active Directory가 중앙 계정 리포지토리가 되더라도 이러한 시스템에서 모든 로컬 SAM(보안 계정 관리자)이나 로컬 계정 저장소가 저절로 사라지지는 않습니다. 이러한 로컬 SAM은 이제 관리와 보안의 대상에서 벗어나기 때문에 오히려 문제의 온상이 됩니다. 여러분의 시스템에서 기본 제공 관리자 계정이나 루트 계정을 마지막으로 변경한 것이 언제입니까? 더구나 모든 계정의 암호 사용 기간을 보여 주고 결과가 감사를 통과하는지 확인하는 보고 유틸리티를 다운로드하여 실행한 경우는 더 드물 것입니다.

여러분이 직접 확인해 보려면 도메인 워크스테이션 중 하나에서 관리자 권한이 있는 도메인 계정으로 로그온해 보십시오. 사용자의 시스템에서 시스템 관리를 열고 ToldYouSo라는 로컬 사용자 계정을 만듭니다. 계정에 이름을 지정하고 이를 사용자 시스템의 로컬 관리자 그룹에 추가합니다. 이제 이 과정을 두 번째 도메인 시스템에서 반복합니다.

이제 두 시스템 중 하나에서 로컬 ToldYouSo 계정으로 로그온한 다음 두 번째 시스템에 액세스하여 \\systemName\c$로 이동해 보십시오. 관리자 공유 위치에 액세스할 수 있는 것은 물론이고 암호를 입력할 필요조차 없습니다! 너무 놀라지는 마십시오. 그러나 심각한 문제인 것은 사실입니다. 다시 반복하자면 시스템이 도메인에 속해 있다고 해도 이러한 모든 시스템은 여전히 작업 그룹에 속해 있는 것처럼 작동합니다.

공유 및 권한이 부여된 계정 암호를 거의 바꾸지 않거나 아예 바꾸지 않는다면 여러분이 공유 및 권한이 부여된 계정은 위험에 노출되어 있는 것입니다. 이 경우에는 시간만 있으면 여러분의 전체 네트워크를 손상시킬 수 있습니다.

다양한 변명들

여러 관리자와 심지어 CIO들과 이야기를 나누어 보면 이러한 계정 암호를 변경하지 않는 몇 가지 같은 이유를 들을 수 있었습니다.

• 시스템은 너무 많고 이러한 계정을 변경할 시간이나 인력이 부족합니다.
• 예산이 부족합니다.
• 관리자 계정을 완전히 사용할 수 없게 비활성화했습니다.
• 아직 피해를 입은 적이 없기 때문에 문제라고 생각하지 않습니다.
• 감사자도 알아차리지 못하는 것 같습니다.

처음 두 가지 이유에 대해서는 필자도 공감하지만 올바른 변명은 아닙니다. 어떤 이유에서든지 이러한 문제를 해결하지 않는 회사에서 필자의 개인 정보를 저장한다고 생각하면 두려워질 정도입니다.

네트워크에 있는 모든 시스템에 민감한 정보가 저장되는 것은 아니지만 이러한 컴퓨터의 사용자는 여러분의 주민 등록 번호나 의료 정보 또는 재무 정보와 같은 중요한 정보에 액세스할 수 있습니다. 시스템의 관리자인 사용자는 키 로거와 화면 캡처 유틸리티를 설치하고 그룹 정책 적용을 중단하며 다양한 하위 시스템에 shim을 추가하여 데이터를 캡처하고 전송하는 등 다양한 작업을 할 수 있습니다. 게다가 사용자가 개별 컴퓨터 수준에서 Administrator라는 이름으로 이러한 작업을 하기 때문에 이러한 악성 사용자를 감지하기가 어렵습니다.

Windows에서 기본 제공 관리자 계정을 비활성화하더라도 계정으로 로그온할 수 있다는 것을 알고 있습니까? 궁금하다면 지금 시스템을 안전 모드로 다시 시작하고 기본 제공 관리자 계정으로 로그온해 보십시오. 원래 이미지에서 계정에 할당된 암호를 사용하면 로그온할 수 있을 것입니다. 이러한 동작에 대한 자세한 내용은 Microsoft® 기술 자료 문서 "HOWTO: Administrator 계정을 해제한 후 컴퓨터에 액세스하기"(support.microsoft.com/kb/814777)를 참조하십시오.

감사관이 원하는 것

SOX, PCI, HIPAA 및 기타 규정을 맞추는 일은 상당히 까다롭습니다. 이들의 요구 사항은 포괄적이고 명확하게 정의되지 않기 때문에 이를 이해하기가 쉽지 않습니다. 일반적으로 이러한 규정에서 요구하는 사항은 다음과 같이 요약할 수 있습니다.

첫째, 모든 권한이 부여된 계정과 정보에 항상 액세스할 수 있도록 보장하고 이를 증명할 수 있는 방법을 마련해야 합니다. 이 요구 사항을 충족하면 모든 시나리오에서 바람직한 결과를 가져옵니다. 권한이 부여된 계정은 임의의 시스템에 무엇이든지 할 수 있는 권한이 있는 계정입니다. 말하자면 기본 제공 관리자 계정, 파이어콜 계정, 그리고 전체 지원 부서 직원과 모든 관리자가 알고 있는 계정입니다.

이러한 공유 계정 암호를 관리하는 솔루션을 구현하도록 선택하면 현재는 존재하지 않는 기본 제공 관리자 계정에 대한 감사 내역을 만드는 것입니다. 즉, 유동적인 암호를 사용하게 되며 솔루션이 자동화되므로 이러한 암호를 변경하느라 소중한 작업 시간을 허비할 필요도 없습니다. 궁극적으로 이러한 솔루션은 감사 기능을 제공하므로 회사가 감사를 통과하는 데도 유리합니다.

자동화된 방법

이러한 계정을 처리하는 가장 효과적인 방법은 주기적으로 계정을 변경하여 두 계정이 같은 암호를 공유하지 않도록 하는 것입니다. 암호가 공유되는 경우 하나의 시스템을 손상되면 다른 시스템도 손상될 수 있다는 의미입니다. 다른 말로 하면 공통적인 로컬이나 도메인 계정을 없애야 합니다.

이러한 암호를 관리하고 불규칙화할 수 있는 자동화 솔루션을 마련할 때는 감사자가 요구하는 최소한의 조건만 충족하는 것에서 만족해서는 안 됩니다. 예를 들어 부가적인 노력 없이도 15, 20 또는 127문자 암호를 사용할 수 있다면 8문자 암호에 만족할 이유가 없습니다(그림 2 참조).

그림 2 자동화를 통해 매우 긴 암호 생성 (더 크게 보려면 이미지를 클릭하십시오.)

또한 그림 3과 같이 권한이 부여된 계정을 매일 불규칙화하는 것도 고려해 볼 수 있습니다. 매달이나 보름 심지어 매일도 할 수 있는 일을 90일마다 할 이유는 없습니다. 무엇보다 절차를 자동화하므로 여러분이 추가로 작업할 필요가 없습니다. 또한 주기적으로 계정을 불규칙화하면 사용자가 도구의 감사되는 검색 인터페이스를 통해 암호를 접수하도록 할 수 있으므로 이전에는 없었던 감사 내역이 추가됩니다. 암호를 적은 봉투를 누군가의 사무실 한쪽에 있는 금고에 저장했다면 이러한 암호에 대해서는 암호 관리 솔루션과 같은 감사 내역을 제공할 수가 없습니다.

그림 3 권한이 부여된 계정을 매일 불규칙화 (더 크게 보려면 이미지를 클릭하십시오.)

마지막으로 사용자가 암호를 접수한 다음에는 일정 기간이 지나면 암호를 다시 불규칙화하도록 할 수 있습니다. 여기에서는 앞서 설명한 예약된 불규칙화를 이야기하는 것이 아니며, 몇 달이 아니라 단 몇 시간만 유효한 일회용 암호를 말하는 것입니다. 이 방법 역시 사용자가 도구의 감사되는 검색 인터페이스에서 암호를 접수해야 하므로 감사 내역이 제공됩니다.

고려할 내용

공유 계정 암호 관리의 문제는 반드시 해결해야 합니다. 즉, 여러분의 암호를 안정적이고 정기적으로 변경할 수 있는 방법을 마련해야 합니다. 이 솔루션은 확장 가능하고 유연해야 합니다. 이 솔루션은 암호에 대한 안전한 액세스를 제공해야 하며, 도구에서 수행한 모든 동작과 모든 도구 사용자가 수행한 동작을 감사할 수 있어야 합니다. 또한 공유된 계정 정보로 인한 침입을 방지할 수 있도록 모든 시스템에 고유한 암호를 생성해야 합니다.

여러 해 동안 많은 공급업체가 이 문제를 해결하기 위해 진출했으며 앞으로도 많은 공급업체가 이 분야에 진출할 것입니다. 모든 새로운 도구에 대해 충분히 조사하고 확인하여 여러분의 환경에 맞는 솔루션을 선택하십시오.

Chris Stoneff는 Lieberman Software(liebsoft.com)의 제품 관리자이자 보안 및 시스템 관리 소프트웨어 개발자입니다. 그의 이러한 추진력을 뒷받침하는 가장 큰 힘은 어떤 일이 특정한 방향으로 일어나는 방식뿐만 아니라 그 이유에 대해서까지 알아내고자 하는 열정입니다.