6.1.1.1. 이름 부여 방식 (Naming Conventions)

사용자명 이름 부여 방식을 미리 만들어둔다면 앞으로 많은 시간을 절약할 수 있습니다. 계속해서 새로운 이름을 생각해내는 방법은 갈수록 적당한 이름을 찾기가 힘들어지지만, 미리 이름 부여 방식을 생각해놓으면 향후 필요한 사용자명을 보다 쉽게 생성 가능합니다. 이름 부여 방식은 매우 간단하거나 또는 몇장에 걸쳐 설명해야할 정도로 복잡할 수도 있습니다.

이름 부여 방식을 결정할 때는 다음과 같은 요소를 고려하셔야 합니다:

• 기업 규모

• 기업 구조

• 기업 특성

기업 규모는 얼마나 많은 사용자 수를 지원해야할지를 결정하는 중요한 요소입니다. 예를 들면 소규모 기업체에서는 개인 이름을 사용자명으로 사용 가능하겠지만, 보다 규모가 큰 기업체에서는 이름이 같은 회사원이 많을 수 있으므로 개인 이름을 사용자명으로 사용하는 것은 적절하지 않습니다.

기업체 구조도 적절한 사용자명을 부여하는데 중요한 요소가 됩니다. 정확히 규정된 구조를 갖춘 기업체에서는 이러한 구조를 염두하여 이름을 부여하는게 좋습니다. 예를 들자면 기업체 부서 코드를 각 사용자 이름의 일부분으로 사용하는 것도 가능합니다.

또한 회사의 성격에 따라서 어떠한 사용자명은 적절하지 않을 수도 있습니다. 기밀 정보를 다루는 기업체에서는 개인에 대한 신상 정보를 밝히는 사용자명을 사용하지 않는 것이 좋습니다. 따라서 이러한 기업에서는 사용자 Maggie McOmie에게 LUH3417와 같은 사용자명을 부여하도록 합니다.

다음은 기업체에서 사용되어온 일부 이름 부여 방식의 예입니다:

• 사용자 이름 (예, john, paul, george)

• 성(姓) (예, smith, jones, brown)

• 이름 첫 글자와 성(姓) 조합 (예, jsmith, pjones, gbrown)

• 성(姓)과 부서 코드 조합 (예, smith029, jones454, brown191)

	힌트
	만일 다른 두가지 자료를 조합하여 사용자명을 생성하는 경우에는 우스꽝스럽거나 모욕적인 사용자명이 될 가능성도 있으니 주의하시기 바랍니다. 따라서 사용자명이 자동으로 생성되는 경우에도 반드시 검토 작업을 수행하시기 바랍니다.

어떠한 이름 부여 방식을 채택하시더라도 한가지 공통점은 언젠가는 동일한 사용자명이 필요한 경우가 생긴다는 것입니다. 이러한 상황은 충돌 (collision) 현상이라고 부릅니다. 각 사용자명은 유일해야 하므로 충돌 현상을 해결하는 것이 중요합니다. 다음은 이러한 문제에 대한 해결 방법을 다루어보겠습니다:

6.1.1.2. 사용자명 변경 요구에 대처하는 방법

만일 여러분이 근무하시는 기업체에서 각 사용자의 이름에 기초한 사용자명을 이용하는 경우 실제로 사용자명을 바꾸어야할 경우가 종종 발생합니다.개인의 이름은 변경되지 않더라도, 가끔씩 사용자명을 바꾸어 달라거나 기업 고위 당직자로서 자신의 이름이 사용자명으로 사용되는 것에 불만족스러워 보다 "적절한" 사용자명으로 바꾸어줄 것을 요구하는 경우가 있을 것입니다.

이유가 어떻든 간에 사용자명을 변경할 때에는 다음과 같은 사항을 염두하셔야 합니다:

• 사용자명을 변경함으로서 영향을 끼칠 모든 시스템에 변경 사항을 적용하기

• 근본적인 사용자 식별 정보는 그대로 유지할 것

• 필요한 경우 모든 파일 및 기타 사용자 관련 자원의 허가권을 변경하기

• 이메일 관련 문제 처리하기

무엇보다 가장 중요한 것은 이전 사용자명이 사용되던 모든 시스템에 새 사용자명을 알리는 작업입니다. 그렇지 않으면 사용자명에 의존하는 일부 운영 체제 기능이 일부 시스템에서는 작동하지만 다른 시스템에서는 제대로 작동하지 않을 수도 있습니다. 특정 운영 체제는 사용자명을 이용한 액세스 제어 기술을 사용합니다. 따라서 이러한 운영 체제에서는 사용자명 변경으로 인한 문제가 자주 발생하게 됩니다.

많은 운영 체제가 사용자 id 번호를 사용하여 대부분의 사용자 관련 프로세스를 처리합니다. 따라서 사용자명이 바뀌면서 발생하는 문제를 최소화하기 위해서는 이전 사용자명과 새 사용자명의 id 번호가 같아야 합니다. 만일 id 번호가 달라지게 되면 사용자가 이전 사용자명으로 소유했던 파일이나 다른 자원을 더 이상 액세스할 수 없게되는 상황이 발생하게 됩니다.

만일 사용자 id 번호를 변경해야 한다면, 반드시 모든 파일과 사용자 관련 자원에서 새 사용자 id 번호를 반영하도록 소유권을 변경해주셔야 합니다. 이 작업을 수행시 항상 중요한 부분을 빠드려 오류가 발생하기 십상이니 주의하셔야 합니다.

사용자명이 변경되었을 경우 이메일과 관련된 문제가 가장 처리하기 어렵다고 할 수 있습니다. 그 이유는 특별히 어떤 방법을 취하지 않는한 이전 사용자명으로 보내진 이메일이 새 사용자명으로 전달되지 않기 때문입니다.

사용자명 변경으로 인한 이메일 관련 문제는 그리 단순하지가 않습니다. 가장 기본적으로 사용자명이 변경되었다는 것은 더 이상 사람들이 그 사용자에 대한 정확한 사용자명을 알고 있지 않다는 사실을 의미합니다. 처음 생각하기에는 그리 복잡한 문제가 아니라고 여기실 수도 있습니다. 모든 회사원에게 새 사용자명을 알리면 되지 않나요?라고 하실 수도 있습니다. 그렇다면 이 사용자에게 이메일을 보낼 회사 외부인에게는 어떠한 방법으로 알리겠습니까? 또한 내부 메일링 리스트 및 외부 메일링 리스트의 경우 어떻게 새 정보를 업데이트하시겠습니까?

이러한 질문에 대한 쉬운 해답은 없습니다. 최선의 방안은 이메일 앨리어스(alias)를 만들어 이전 사용자명으로 보내진 이메일을 모두 새 사용자명으로 자동으로 전송되도록 설정한 후 사용자는 이메일을 받는 즉시 이전 이메일 주소로 보낸 상대방에게 자신의 새 사용자명을 알리도록 하는 것입니다. 시간이 흐르면서 이 앨리어스를 사용하여 전송되는 이메일 메시지 수가 점차 줄어들 것이며 결국 앨리어스가 필요없게 됩니다.

이렇게 앨리어스를 사용하게 되면 외부 사용자에게 이전 사용자명이 아직 존재하는 것처럼 잘못된 인상을 줄 가능성도 있지만 (예를 들어 새 사용자명은 esmith로 바뀌었지만 외부 사용자는 아직 ejones로 계속 이메일을 보내는 경우), 이메일을 적절한 사람에게 전달하기 위해서는 앨리어스를 사용하는 것이 유일한 방법입니다.

	중요
	이메일 앨리어스를 사용하시는 경우 이전 사용자명이 다른 사용자에 의해 다시 사용되지 않도록 모든 조치를 취하셔야 합니다. 만일 다른 사용자가 여러분의 이전 사용자명을 사용하기 시작하면, 기존 사용자와 새 사용자 모두 이메일을 제대로 전달받을 수 없게 됩니다. 운영 체제에서 이메일 전달 방식이 어떻게 설정되었느냐에 따라 결과는 달라지지만, 일반적으로 다음과 같은 현상이 발생할 가능성이 높습니다: 새 사용자에게는 아무런 이메일도 전달되지 않음 — 모든 이메일이 이전 사용자에게 전달됨. 이전 사용자에게는 갑자기 아무런 이메일도 전달되지 않음 — 모든 이메일이 새 사용자에게 전달됨.

6.1.2.1. 약한 암호

앞서 언급되었듯이, 약한 암호란 다음과 같은 세가지 테스트를 통과하지 못한 경우를 말합니다:

• 암호의 비밀 유지

• 추측해내기 어려움

• 가능한 모든 암호를 대입하는 공격(brute-force attack)에도 쉽게 밝혀지지 않음

다음에서는 약한 암호의 예를 들어보겠습니다.

6.1.2.1.1. 짧은 암호

짧은 암호는 brute-force 공격으로 쉽게 알아낼 수 있으므로 약한 암호입니다. 보다 쉽게 설명하기 위하여 다음 표를 예로 들어보겠습니다. 다음 표는 암호 길이에 따라서 얼마나 많은 brute-force 공격이 행해져야하는지를 보여줍니다 (이 표에서는 암호가 모두 소문자라고 가정합니다):

암호 길이	가능한 암호 조합수
1	26
2	676
3	17,576
4	456,976
5	11,881,376
6	308,915,776

표 6-1. 암호 길이 대 가능한 암호 조합수

이 표에서 볼 수 있듯이 암호 길이가 길수록 가능한 암호 조합수도 증가됩니다.

	알림
	비록 이 예시에서는 6 글자에서 멈췄지만, 절대로 6글자 정도로 암호를 설정하면 충분히 안전하다는 의미는 절대 아닙니다. 일반적으로 암호는 길면 길수록 좋습니다.

6.1.2.1.3. 사전에 나온 용어

많은 침입자들은 사용자가 자신이 쉽게 기억할 수 있는 암호를 사용한다는 점을 이용하여 암호를 추측해냅니다. 사용자가 쉽게 기억할 수 있는 암호란 대부분 사전에 등록된 단어를 말합니다. 즉, 침입자는 사전에 나온 단어를 이용하여 암호 찾기를 시도합니다.

	알림
	많은 사전 기반 암호 공격 프로그램은 여러 언어 사전을 사용합니다. 따라서 영어가 아닌 단어를 암호를 사용한다고 해서 안심하시면 절대 안됩니다.

6.1.2.2. 강력한 암호

지금까지 약한 암호의 특징에 대하여 이야기해보았습니다. 이제 강력한 암호의 특징에 대하여 설명해보겠습니다.

6.1.2.2.3. 기억 가능한 암호

암호가 아무리 강력하다고 해도 기억할 수 없다면 아무 소용없습니다. 그러나 가끔씩 기억하기 쉬운 암호는 추측하기 쉬운 암호가 되는 경우가 많습니다. 따라서 기억 가능하지만 쉽게 추측해내기 힘든 암호를 생성하는 방법에 대한 사용자 교육이 필요합니다.

예를 들어 좋아하는 문구나 속담을 생각해보신 후 각 단어의 첫글자를 따서 암호를 만들 수 있습니다. 이렇게 만든 암호는 여러분이 좋아하시는 문구의 각 단어 첫글자를 사용했기 때문에 기억하기는 쉽지만, 한단어로는 아무런 의미가 없기 때문에 제3자가 추측하기는 매우 어렵습니다.

	알림
	그러나 문구의 첫 단어를 이용하는 것만으로는 강력한 암호의 조건에 충분치 않습니다. 항상 준비된 암호에 숫자와 문자를 조합하고 최소한 한개 이상의 특수 문자도 첨가하여 암호 보안을 높이는 것을 잊지 마십시오.

6.1.2.3. 암호 사용기한 설정하기

가능하다면 기업내에서 암호 사용기한을 설정하십시오. 암호 사용기한(password aging) 기능은 주어진 암호를 사용 가능한 기간을 제한하는 기능으로서 많은 운영 체제에서 설정가능합니다. 암호가 만료되기 이전에 사용자는 새 암호를 입력하도록 요청될 것입니다.

많은 시스템 관리자가 암호 사용기한을 설정시 자주 묻는 질문이 있습니다. 얼마나 길게 설정할 것인가?

암호 기한만료와 관련하여 다음과 같은 두가지 상반되는 사항이 대두됩니다:

• 사용자 편의

• 보안

한가지 극단적인 예를 들자면 암호 사용기한을 99년으로 설정할 경우 사용자는 매우 편하겠지만, 거의 아무런 보안을 제공하지 않습니다.

또 다른 극단적인 예로서 암호 사용기한을 99분으로 설정한 경우 사용자에게는 극히 불편하겠지만 보안은 매우 높아집니다.

따라서 사용자의 편의와 회사의 보안을 동시에 고려하여 선택하는 것이 좋습니다. 대부분의 기업체에서는 암호 사용기한이 몇주에서 몇달 단위로 설정됩니다.

6.1.4.1. 신입 사원이 입사할 경우

새로운 직원이 입사하면, 그 직원의 역할에 따라서 다양한 자원(예, 책상, 전화기, 열쇠 등)을 할당받게 됩니다.

또한 이 신입 사원이 여러 대의 컴퓨터를 사용하게될 경우도 있습니다. 이러한 작업이 신속하고 적절히 수행될 수 있도록 돕는 것은 시스템 관리자의 책임이라 할 수 있습니다. 그렇다면 어떠한 방법을 사용하여 믿을 수 있게 작업을 수행하시겠습니까?

무엇보다도 먼저 시스템 관리자는 신입 사원이 시작하는 날짜를 알고있어야 합니다. 다음과 같은 방법을 사용하시는 것이 좋습니다:

• 신입 사원이 입사할때마다 인사부 직원이 시스템 관리자에게 통보하도록 절차를 세우십시오.

• 신입 사원의 상사가 새로운 계정을 신청하는데 사용할 서식을 만들어 놓으십시오.

각 기업체마다 이러한 절차는 다를 수 있지만, 가장 중요한 점은 사용자 계정과 관련된 작업을 신속하게 처리할 수 있는 확실한 절차를 세워야한다는 것입니다.

6.1.4.2. 직원이 전직 또는 해고당할 경우

언젠가는 누군가 회사를 떠날 것이라는 사실은 부정할 수 없습니다. 가끔씩은 좋은 이유에서 또 다른 경우에는 안좋은 이유로 회사를 그만두게 될 것입니다. 어떠한 경우에서건 시스템 사용자로서 적절한 조치를 취하기 위해서는 언제 누가 그만두게 되었는지 잘 알고있어야 합니다.

이러한 경우 최소한 다음과 같은 작업을 행하셔야합니다:

• 해당 사용자의 시스템 및 관련 자원 액세스 권한을 모두 취소하기 (보통 이 작업은 사용자의 암호를 바꾸거나/잠그면 됩니다)

• 향후 필요할 경우에 대비하여 사용자의 파일을 백업해두기

• 그만둔 사용자의 상사와 함께 해당 사용자의 파일 액세스 허가를 조정하기

가장 시급한 작업은 회사를 구만둔 직원으로부터 회사 시스템을 보호하는 작업입니다. 특히 해당 직원이 좋지 않은 이유로 회사에서 해고를 당한 경우 더욱 중요합니다. 이렇게 심각한 경우가 아니더라도 시스템 관리자로서 보다 신속하고 확실하게 회사를 그만둔 직원의 액세스 권한을 취고하는 것이 좋습니다.

시스템 관리자가 적절한 조치를 취하기 위해서는 해당 직원이 실제로 회사를 그만두기 이전에 미리 이 소식이 시스템 관리자에게 전해져야 합니다. 따라서 시스템 관리자는 인사부 직원과 긴밀하게 협조하여 다가오는 인사 해고나 전직 소식을 즉시 전달받을 수 있도록 확인하시기 바랍니다.

	힌트
	직원이 해고되거나 전직하여 시스템을 "잠그는" 작업을 수행시에는 타이밍을 중요합니다. 만일 직원이 회사를 떠나고 난 후 잠금 작업을 수행한다면, 이 직원이 그 사이에 허가받지 않은 작업을 행할 위험이 존재합니다. 다른 한편으로 실제로 직원이 해고되기 이전에 사용자 계정을 잠그게되면, 본인이 미리 사실을 알게되어 모든 관계자에게 일을 진행하기 힘든 상황을 초래할 수도 있습니다. 해고 절차는 보통 해고당하는 장본인과 상사, 그리고 인사부 대표자가 함께 만나면서 시작됩니다. 따라서 이러한 회의가 시작되면 곧 바로 시스템 관리자에게 통보하는 절차를 세우게되면, 향후 적절한 시기에 사용자 계정을 잠그는데 큰 도움이 됩니다.

일단 사용자 계정을 취소하셨다면, 이제 그 직원의 파일을 백업하셔야 합니다. 이 백업은 기본적인 기업 백업 절차를 따르거나 또는 특별히 회사를 떠난 사용자 계정을 백업하는 절차에 따를 수도 있습니다. 만일 직원이 부당한 이유로 해고당했다고 생각하고 회사에 소송을 걸 경우 증거 자료로서 이 직원의 파일을 백업하는 경우와 같이 상황에 따라서 가장 적절한 백업 절차를 선택하셔야 합니다.

다음 단계 (상사가 회사에서 떠난 직원의 파일을 관리하는 과정)에서 실수로 파일이 삭제될 위험이 있으니 미리 백업해두시는 것이 좋습니다. 상사가 실수로 파일을 삭제해도 미리 준비된 백업이 있으니 쉽게 복구할 수가 있습니다.

이 시점에서 시스템 관리자는 상사가 어느 정도의 허가를 가지고 파일을 살펴볼 수 있을지 결정해야 합니다. 기업체와 상사의 역할에 따라서 모든 파일에 액세스할 수 있을 경우도 있고, 아무런 파일도 볼 수 없을 경우도 있습니다.

만일 사용자가 시스템을 개인적인 용도로도 사용해왔다면 상사는 버릴 파일과 보존할 파일을 걸러내야 합니다. 또한 마지막 작업으로서 해고당한 직원을 대체하는 새 직원에게 이전 파일을 전해주어야할 경우도 있습니다. 기업체의 성격과 파일에 따라서 상급자를 보조하는 것이 시스템 관리자의 역할입니다.

6.1.4.3. 직원의 직급이 변경될 경우

신입 사원을 위한 새로운 계정을 생성하는 일이나 해고당한 직원의 계정을 잠그는 작업은 상대적으로 간단한 작업입니다. 그러나 어느 직원의 역할이 기업내에서 변경되었을 경우에는 그리 간단하지 않습니다. 경우에 따라서 이 직원의 계정을 변경해야할 수도 있고 그렇지 않을 수도 있습니다.

직급이 변경된 직원의 새로운 역할에 맞게 적절히 사용자 계정을 재설정하기 위해서는 최소한 다음과 같은 세사람의 도움이 필요합니다:

• 시스템 관리자

• 사용자의 이전 상사

• 사용자의 새 상사

이 세 사람이 협력하여 이 직원의 이전 역할에 주어진 계정을 깨끗하게 잠그어 마무리하고, 새 역할에 맞는 계정을 생성하기 위하여 어떠한 작업이 필요한지 결정하셔야 합니다. 여러 방면에서 이 작업은 기존 사용자의 계정을 지우고 새 계정을 생성하는 과정과 같다고 생각하시면 됩니다. 실제로 일부 기업에서는 직원의 직급이 변경될 때마다 기존 계정을 지우고 새 계정을 생성하는 작업을 수행합니다.

그러나 대부분의 경우 사용자 계정을 완전히 삭제하고 새로 만들기 보다는 기존 계정을 새로운 역할에 맞도록 수정하는 방법을 많이 사용합니다. 이러한 방법을 사용할 경우 시스템 관리자는 새 계정이 새로운 역할에 맞는 자원과 권한만 가지도록 신중하게 확인하셔야 합니다.

가끔씩 직급 이동 과정에서 직원이 이전 역할과 새로운 역할을 동시에 수행해야하는 경우에는 일이 생각보다 복잡해질 경우가 있습니다. 이 시점에서 시스템 관리자는 이전 상사와 새 상사의 도움을 받아 정확한 이동 시기를 알아낼 수 있습니다.