누군가에게 사서함을 제공할 때 흔히 사용하는 방법은 관리자가 사서함을 만들고 비밀번호를 정한 뒤 주소와 비밀번호를 사용자에게 보내는 것입니다. 잘못된 방법이라는 사실을 모두 알면서도 거의 모두가 그렇게 합니다. 예전에는 다른 방법이 더 번거로웠기 때문입니다. 설정 초대를 사용하면 이런 이유도 사라집니다. 관리자는 비밀번호를 정하지 않으며, 누구도 이메일이나 채팅으로 비밀번호를 공유할 필요가 없습니다.
이 글에서는 초대가 작동하는 방식, 비밀번호를 공유하지 않는다는 결정이 생각보다 중요한 이유, 그리고 이 방식이 2단계 인증과 퇴사자 계정 처리에 어떤 영향을 주는지 설명합니다.
문제가 생기지 않더라도 비밀번호를 공유해서는 안 되는 이유
비밀번호를 공유해서는 안 되는 가장 분명한 이유는 가로채기 위험입니다. 이메일이나 채팅 메시지로 보낸 비밀번호는 최소 두 개의 사서함에 기한 없이 남고, 검색할 수 있으며, 모든 백업에도 보존됩니다. 나중에 어느 한쪽 계정에 접근한 사람은 비밀번호를 찾을 수 있습니다. NIST 지침도 오랫동안 이런 방식으로 비밀 정보를 전송하지 말라고 권고해 왔습니다.
덜 눈에 띄지만 더 오래가는 문제는 비밀번호가 변경되지 않는다는 점입니다. 원칙상 사용자가 처음 로그인할 때 자신의 비밀번호로 바꿔야 하지만, 실제로는 관리자가 보낸 비밀번호가 잘 작동하고 변경을 강제하는 절차도 없어서 그대로 사용합니다. 몇 달 뒤에도 관리자는 다른 사람의 사서함에 로그인할 수 있는 정보를 알고 있습니다. 그러면 해당 사서함에서 일어난 행동이 사용자의 것이라고 주장할 근거가 조용히 무너집니다.
분쟁이 생겼을 때 중요한 것은 마지막 문제입니다. 두 사람이 같은 비밀번호를 알고 있으면 그 계정에서 수행된 작업을 어느 한 사람의 행동이라고 확신할 수 없습니다. 비밀번호를 공유하지 않아도 되는 구조는 단순히 더 안전한 것이 아닙니다. 감사 기록에 의미를 부여하기 위한 전제 조건입니다.
초대로 비밀번호 공유를 없애는 방법
관리자는 비밀번호 없이 사서함을 만듭니다. 시스템이 사용할 사람에게 이메일로 링크를 보내고, 사용자는 링크를 열어 자신의 비밀번호를 직접 정합니다. 로그인 정보가 다른 사람의 손을 거치는 순간은 전혀 없습니다.
따라서 로그인 정보가 다른 사람에게 보이는 형태로 존재한 적이 없습니다. 보낸편지함에도, 채팅 기록에도 남지 않으며, 관리자가 알고 있다는 사실을 잊어버릴 일도 없습니다.
초대는 한 명씩 또는 일괄로 보낼 수 있습니다. 이 기능이 있어야 좋은 아이디어가 실제 운영 가능한 방식이 됩니다. 신규 고객을 위해 사서함 40개를 프로비저닝할 때 비밀번호 40개를 만들고 기록하고 전송하는 대신 한 번의 작업으로 초대 40개를 보낼 수 있습니다. 일괄 처리 방식은 사서함 일괄 생성에서 설명합니다.
나머지 절반은 2단계 인증입니다
비밀번호를 공유하지 않으면 한 가지 허점은 막을 수 있지만 다른 허점은 남습니다. 사용자만 아는 비밀번호라도 약하거나 다른 서비스에서 재사용한 비밀번호일 수 있습니다.
2단계 인증이 두 번째 허점을 막아줍니다. 사용자는 초대 과정이 아니라 웹메일 설정에서 직접 등록합니다. 별도의 안내와 습관이 필요한 절차이므로, 사용 흐름이 강제해 주기를 기대하지 말고 관리자가 도입을 요청해야 합니다.
따라서 초대를 보낼 때 2단계 인증 설정도 요청하고, 일주일 뒤 다시 확인하세요. 대시보드의 사서함 보안 페이지에는 2단계 인증이 활성화된 사서함과 인증이 확인된 시점이 표시됩니다. 누락된 사용자를 추측할 필요 없이 목록으로 확인할 수 있습니다.
복구 코드도 동시에 보관하도록 요구하세요. 계정 소유자는 대시보드에서 사서함의 2단계 인증을 해제할 수 없으므로, 사용자에게 기기와 복구 코드가 모두 없다면 지원 티켓을 제출해야 합니다. 전체 절차는 2FA 잠금 해결 방법에서 확인할 수 있습니다.
관리자의 업무가 달라지는 방식
비밀번호를 공유하지 않기로 하면 한 가지 조정이 필요한 대신 관리자의 업무는 대부분 줄어듭니다.
관리자가 로그인 정보를 보관하지 않으므로 관련 요청 한 종류가 통째로 사라집니다. "제 비밀번호가 뭐였는지 알려주시겠어요?"라는 요청은 사용자가 직접 수행하는 비밀번호 재설정으로 바뀝니다. 관리자가 신뢰를 전제로 다른 사람의 비밀번호를 맡을 필요도 없어집니다. 동료가 아니라 고객의 사서함을 관리할 때는 특히 큰 부담을 덜 수 있습니다.
달라지는 점은 관리자가 무언가를 확인하려고 다른 사람의 사서함에 로그인할 수 없다는 것입니다. 처음에는 불편하지만 언제나 올바른 제한입니다. 회사가 업무 연락에 접근해야 한다면 사용자의 비밀번호를 관리자가 아는 방식이 아니라 구성원 권한을 사용하는 공유 사서함을 사용해야 합니다. 두 방식은 책임 소재가 서로 다른 별개의 구조이며, 이를 혼동하지 않는 것이 비밀번호 공유 금지 원칙의 핵심입니다.
여전히 주의가 필요한 경우
설정만 켜두고 잊어서는 안 되며 조금 더 고민해야 할 상황이 두 가지 있습니다. 기억에 의존하지 말고 정기적으로 확인할 가치가 있습니다.
초대 절차를 완료하지 않은 사용자. 아직 사용자 설정이 완료되지 않은 사서함은 아무도 읽지 않는 사서함이며, 그동안 이메일은 계속 도착할 수 있습니다. 초대에 만료 기한이 있는 것은 올바른 설계지만, 담당자가 완료했다고 가정하지 말고 실제 사용자가 설정을 마쳤는지 확인해야 합니다.
사람이 아니라 대상에 속한 주소. 부동산이나 작업 번호를 위한 사서함에는 초대할 사용자가 없습니다. 처음부터 구성원 권한을 사용하는 공유 사서함으로 만들어 접근 권한을 자격 증명 하나가 아니라 구성원 목록으로 관리해야 합니다. 그렇지 않으면 결국 다른 경로를 거쳐 공용 비밀번호를 사용하게 됩니다.
초대가 만료되어야 실수로 비밀번호를 공유하지 않습니다
설정 링크가 기한 없이 유효하다면 절차만 더 복잡해진 비밀번호와 다르지 않습니다. 따라서 초대에는 유효 기간이 있고 시간이 지나면 작동하지 않습니다.
실제로 근무를 시작하기 훨씬 전에 계정을 만들면 링크가 만료되고, 첫 출근 날 혼란스러운 이메일을 주고받게 됩니다. 사용자가 사서함을 사용할 준비가 됐을 때 초대를 보내세요. 만료된 링크를 다시 살리려고 쫓아다니지 말고 새 초대를 발급하는 편이 낫습니다. 몇 초면 끝납니다.
다른 곳에서도 비밀번호를 공유하지 마세요
사서함의 로그인 정보를 주고받지 않게 되면 다른 시스템에서도 같은 질문이 생깁니다. 이 원칙을 계속 적용할 가치가 있습니다.
저장 공간의 공용 로그인, 여러 장치에서 함께 쓰는 앱 비밀번호, 세 개의 스크립트가 사용하는 API 토큰 하나는 모두 같은 약점을 가집니다. 한 주체의 접근만 취소하려 해도 모두의 작업을 중단해야 합니다. 저장 공간에 장치별 로그인 정보를 사용하면 같은 문제를 해결할 수 있습니다. 자세한 내용은 여러 장치 간 파일 동기화에서 설명합니다.
이 원칙은 어디에나 적용됩니다. 둘 이상의 주체가 아는 자격 증명은 그중 한 사람의 접근만 취소할 수 없고, 어떤 행동을 어느 한쪽의 것으로 특정할 수도 없습니다. 비밀번호를 공유하지 않는 구조의 주된 목적은 비밀 유지가 아닙니다. 다른 모두에게 영향을 주지 않고 특정 사용자 한 명에 대한 접근 결정을 변경할 수 있게 하는 것입니다.
