비밀번호를 보호하는 대신 없앨 수 있다면?

우리가 당연한 것으로 여겨 온 문제

거의 모든 웹 애플리케이션에는 관리자 패널이 있습니다. 그리고 관리자 패널에는 대개 로그인 주소와 인증 양식, 아이디와 비밀번호가 있습니다.

우리는 이런 구조에 너무 익숙해진 나머지, 모든 것이 꼭 이런 방식으로 작동해야 하는지 거의 묻지 않게 되었습니다.

사이트가 하나뿐일 때는 문제가 대수롭지 않아 보입니다. 복잡한 비밀번호를 만들고, 2단계 인증을 활성화하고, 로그인 시도 횟수를 제한하면 됩니다.

하지만 프로젝트가 열 개, 스무 개, 서른 개로 늘어나면 어떻게 될까요?

제 경우에는 독립적인 소프트웨어 프로젝트 30개 이상을 아우르는 DigiMeld 생태계가 있습니다. 각 프로젝트는 저마다의 아키텍처와 서버 로직, 관리자 인터페이스를 갖추고 있습니다.

따라서 각 프로젝트에는 관리자 접근 수단이 필요합니다.

오랫동안 저는 꽤 익숙한 방식을 사용했습니다. 프로젝트마다 별도의 관리자 계정을 만들고, 복잡한 비밀번호를 설정해 브라우저에 저장해 두는 방식이었습니다.

잘 작동했습니다.

하지만 어느 순간 이런 생각이 들었습니다. 왜 관리자 비밀번호를 이렇게 많이 저장해야 할까? 왜 서버뿐 아니라 서버에 접근할 수단까지 보호해야 할까?

이런 필요 자체를 없앨 수는 없을까?

복잡한 비밀번호만으로는 문제 자체가 해결되지 않는다

오늘날의 도구를 사용하면 엔트로피가 매우 높은 비밀번호를 만들 수 있습니다. 올바르게 생성된 길고 무작위적인 비밀번호는 무차별 대입으로 알아내기가 사실상 불가능합니다.

하지만 비밀번호가 아무리 복잡해도 어딘가에 저장한 다음 사용해야 합니다.

비밀번호 관리자와 하드웨어 보안 키, 다중 인증, 추가 제한을 사용할 수 있습니다. 이런 방법은 실제로 보안을 강화합니다.

그렇더라도 근본적인 아키텍처 구조는 그대로 남습니다. 사용자가 자격 증명을 제시하는 특정 인터페이스가 존재한다는 점입니다.

그 인터페이스로 요청을 보낼 수 있고, 스캔할 수도 있으며, 자동화된 공격의 표적이 될 수도 있습니다.

관리자 패널 주소를 숨기거나, 기본 경로를 길고 무작위적인 문자열로 바꾸거나, IP 주소로 접근을 제한할 수 있습니다.

하지만 그러면 새로운 문제가 생깁니다. 그 주소를 어디에 저장하고 어떻게 이용할까요?

그리고 무엇보다 중요한 질문은 이것입니다. 관리자 접근이 특정한 순간에만 필요한데, 왜 상시 로그인 경로를 유지해야 할까요?

저는 나중에 제 솔루션의 바탕이 된 생각에 이르렀습니다.

상시 존재하는 로그인 경로가 아니라, 일시적으로 접근 권한을 얻을 수 있는 권리 자체를 보호해야 할지도 모릅니다.

익숙한 로그인 페이지가 아예 없다면 어떨까?

저는 제 프로젝트에서 기존의 관리자 인증 방식을 없애기로 했습니다.

로그인 양식을 단순히 숨기는 것이 아닙니다.

주소를 바꾸는 것도 아닙니다.

비밀번호를 더 복잡한 비밀번호로 바꾸는 것도 아닙니다.

상시 존재하는 비밀번호 로그인 자체가 필요하지 않도록 하는 것입니다.

물론 관리자 인터페이스가 사라진 것은 아닙니다. 애플리케이션을 관리하려면 여전히 필요합니다.

바뀐 것은 관리자 인터페이스에 접근하는 방식입니다.

이제 연결된 프로젝트의 관리자 패널에 로그인할 때 저장된 아이디와 비밀번호를 입력할 필요가 없습니다.

대신 자체적으로 구축한 신원 확인 및 접근 관리 시스템 MeldID를 사용합니다.

원리는 간단합니다. 관리자 접근 권한은 실제로 필요할 때, 특정 사용자에게, 특정 프로젝트에만 부여됩니다.

계정이 있다는 사실만으로 관리자 패널을 열 권리가 생기는 것은 아닙니다.

그 권한은 별도로 부여해야 합니다.

1분 전에는 존재하지 않았던 접근 권한

이것이 아마 전체 개념에서 가장 흥미로운 부분일 것입니다.

기존 방식에서는 관리자가 늘 로그인 수단을 갖고 있습니다. 그 수단이 유효한 동안에는 오늘이든 내일이든 한 달 뒤든 사용할 수 있습니다.

저는 이 원칙을 바꾸기로 했습니다.

상시 유효한 관리자 자격 증명 대신, 일시적으로 로그인을 시작할 수 있는 수단을 사용합니다.

이 수단은 신뢰할 수 있는 모바일 기기를 통해 요청할 때 생성되며, 암호학적으로 안전한 무작위 요소를 포함하고 유효 기간이 제한됩니다.

하지만 이런 임시 링크를 가지고 있다는 사실만으로 접근 권한이 생기는 것은 아닙니다.

이 점이 핵심입니다.

누군가 어떤 경로로든 링크를 얻었다고 가정해 봅시다. 주소의 비밀성에만 의존하는 일반적인 시스템이라면 이런 유출은 심각한 문제가 될 수 있습니다.

제 모델에서 링크는 확인 절차를 시작하는 역할만 합니다.

절차를 계속 진행하려면 신뢰할 수 있는 MeldID 모바일 기기에서 별도로 허가해야 합니다.

적절한 확인이 없으면 관리자 세션은 생성되지 않습니다.

그래서 저는 임시 링크를 비밀번호의 대체물이 아니라 접근 권한을 부여하는 절차의 한 요소로 봅니다.

어디로 가야 하는지 아는 것과 로그인할 권리가 있는 것은 전혀 다른 일입니다.

휴대전화가 접근 관리 도구가 되다

이 모델에서 모바일 기기는 일회용 코드를 생성하는 일반적인 도구보다 훨씬 중요한 역할을 합니다.

관리자 접근과 관련된 작업을 확인하는 데 사용됩니다.

관리자 패널을 열려고 하면 시스템이 MeldID를 통해 확인을 요청합니다.

신뢰할 수 있는 기기에서 해당 요청을 확인하고 작업을 승인합니다.

검증이 성공한 뒤에야 시스템이 로그인 절차를 계속 진행하도록 허용합니다.

이때 확인은 단순히 휴대전화 잠금이 해제되었다는 사실이 아니라, 특정 작업과 연결되어 있습니다.

모바일 생체 인증으로 기기에서 사용자를 확인하고, 서버는 등록된 기기에서 온 암호학적 확인 정보를 검증합니다.

이런 방식은 비밀번호나 사용자가 로그인을 확인했다고 알려 주는 메시지에만 의존하지 않게 해 줍니다.

또 다른 장점도 있습니다. 신뢰할 수 있는 기기를 관리할 수 있다는 점입니다.

더 이상 어떤 기기를 접근 확인에 사용해서는 안 된다면, 그 기기의 신뢰 상태를 해제할 수 있습니다.

그렇게 하면 해당 기기는 관련 작업을 인증하는 유효한 수단이 아니게 됩니다.

하나의 시스템, 여러 독립 프로젝트

이 메커니즘을 개발하기 시작했을 때 가장 중요한 과제 중 하나는 각 프로젝트의 독립성을 유지하는 것이었습니다.

모든 관리자 패널을 하나의 거대한 애플리케이션으로 통합하고 싶지는 않았습니다.

각 DigiMeld 서비스는 계속해서 자체 로직과 설정, 사용자, 데이터를 관리해야 합니다.

그래서 두 가지 역할을 분리했습니다.

MeldID는 신원 확인과 관리자 접근 권한 부여를 담당합니다.

각 프로젝트는 자체 관리자 기능과 현재 유효한 권한의 확인을 담당합니다.

그 결과 애플리케이션 자체를 중앙화할 필요 없이 접근 관리를 중앙화할 수 있었습니다.

또한 권한은 각각 별도로 부여됩니다.

한 프로젝트의 관리자가 MeldID 계정을 가지고 있다는 이유만으로 다른 프로젝트에 자동으로 접근할 수 있는 것은 아닙니다.

관리자 권한이 필요한 각 영역마다 허용된 사용자를 별도로 지정할 수 있습니다.

일반 사용자 권한과 관리자 권한도 서로 분리되어 있습니다.

수십 개 서비스로 이루어진 생태계에서는 특히 편리했습니다.

상시 접근보다 임시 접근이 더 마음에 드는 이유

제가 의도적으로 시스템에 반영한 원칙이 하나 더 있습니다.

관리자 접근 권한이 무기한 유지되어서는 안 됩니다.

권한은 제한된 시간 동안만 유효하며, 사용자가 브라우저에서 계속 작업 중인지와 관계없이 만료됩니다.

만료 후에도 작업을 계속하려면 확인 절차를 다시 진행해야 합니다.

이렇게 하면 한 번 완료한 인증이 계속 유효한 권한으로 남는 것을 막을 수 있습니다.

하지만 유효 시간 제한만으로는 충분하지 않습니다.

이미 부여한 접근 권한을 만료 전에 취소할 수 있는 것도 중요합니다.

그래서 MeldID에는 관리자 권한을 중앙에서 취소하는 기능이 있습니다.

권한을 취소하면 연결된 프로젝트에 해당 이벤트가 전달되고, 프로젝트는 관련 관리자 세션을 무효화합니다.

이렇게 접근 관리는 사용자가 성공적으로 로그인한 순간에 끝나지 않습니다.

저에게 권한을 부여할 수 있는 능력은 권한을 취소할 수 있는 능력만큼 중요합니다.

분산 시스템에서는 이벤트 전달 지연이나 일부 구성 요소의 일시적인 이용 불가 등 운영상의 여러 상황도 고려해야 합니다. 세션의 유효 기간 제한은 추가적인 안전장치 역할을 합니다.

일상적인 업무는 어떻게 달라졌을까?

무엇보다 저장해 둔 관리자 비밀번호를 계속 찾아 쓸 필요가 없어졌습니다.

연결된 각 관리자 패널에 로그인하기 위한 여러 계정 정보를 브라우저에 보관할 필요가 없습니다.

대신 하나의 메커니즘으로 권한을 관리합니다.

필요한 프로젝트를 선택하고 접근을 확인한 뒤 작업하면 됩니다.

관리자 접근이 더 이상 필요하지 않으면 권한을 취소할 수 있습니다.

특히 새 프로젝트를 추가할 때마다 관리자 인증 시스템 전체를 다시 설계할 필요가 없다는 점이 편리합니다.

기존 모델에 프로젝트를 연결하고 필요한 권한을 지정하면 됩니다.

물론 그렇다고 해서 모든 보안 위험이 사라지는 것은 아닙니다.

임시 권한과 신뢰할 수 있는 기기, 서버 세션, 중앙 인프라 역시 보호해야 합니다.

하지만 이제 각 애플리케이션마다 관리자 비밀번호 관리 문제를 따로 해결할 필요는 없습니다.

이것이 제가 처음부터 이루고자 했던 목표 중 하나였습니다.

이런 기술은 이미 존재하지 않나요?

물론 존재합니다.

비밀번호 없는 인증과 특권 접근 관리, 임시 권한, 신뢰할 수 있는 기기를 통한 확인은 정보 보안 업계에서 오래전부터 알려진 개념입니다.

이런 접근 방식은 Identity and Access Management, Privileged Access Management 시스템과 Zero Trust 개념에서 찾아볼 수 있습니다.

제가 이런 원칙을 발명했다고 주장하는 것은 아닙니다.

제 목표는 달랐습니다.

DigiMeld 인프라의 구체적인 문제를 해결하고, 여러 독립 프로젝트의 관리자 접근을 관리할 수 있는 자체 통합 시스템을 만드는 것이 필요했습니다.

그 결과 제가 요구하는 조건에 맞는 하나의 아키텍처에 여러 가지 알려진 접근 방식을 결합했습니다.

그리고 엔지니어링 작업의 가치는 반드시 완전히 새로운 기술을 발명하는 데만 있는 것은 아니라고 생각합니다.

때로는 문제를 정확히 정의하고 그에 맞는 해결책을 찾는 데 가치가 있습니다.

MeldID는 관리자 패널만을 위한 것이 아니다

여기서 한 가지 별도로 짚고 넘어가야 할 점이 있습니다.

MeldID는 제 관리자 접근만을 위한 도구로 만들어진 것이 아닙니다.

개발자가 자신의 애플리케이션에 신원 확인 및 로그인 승인 기능을 통합할 수 있도록 SDK도 제공합니다.

이 SDK는 무료로 이용할 수 있습니다.

예를 들어 외부 개발자는 MeldID를 사용자 인증을 확인하는 추가 단계로 사용할 수 있습니다.

애플리케이션에서 기존처럼 아이디와 비밀번호로 로그인하더라도, 이 정보를 성공적으로 입력하는 것만으로 인증이 완료되지 않도록 할 수 있습니다.

사용자의 신뢰할 수 있는 모바일 기기에 요청이 전송되고, 사용자는 로그인 시도를 승인하거나 거부합니다.

이렇게 하면 자격 증명이 유출되었을 때 무단 접근이 발생할 위험을 줄일 수 있습니다.

이처럼 누구나 이용할 수 있는 MeldID 기능과 제가 DigiMeld 프로젝트를 위해 개발한 관리자 접근 모델은 구분해야 합니다.

두 방식은 신뢰와 작업 확인이라는 공통 원칙을 사용하지만 서로 다른 문제를 해결합니다.

보안은 이미 존재하는 것을 보호하는 데 그치지 않는다

이 시스템을 개발하면서 익숙한 인증 메커니즘을 다른 시각으로 보게 되었습니다.

우리는 역사적인 이유로 존재하는 것을 보호하려고 할 때가 많습니다.

새로운 검증과 제한, 추가 비밀번호, 보호 계층을 계속 덧붙입니다.

때로는 그것이 정말 필요합니다.

하지만 때로는 다른 질문을 던지는 편이 더 낫습니다.

보호하려는 메커니즘 자체가 꼭 예전과 같은 형태로 존재해야 할까요?

제 경우에는 그렇지 않았습니다.

상시 접근 가능한 관리자 로그인 양식은 필요하지 않았습니다.

필요했던 것은 관리자 권한이 필요한 바로 그때 안전하게 부여받을 수 있는 방법이었습니다.

이 둘은 서로 다른 문제입니다.

첫 번째 방식에서 두 번째 방식으로 전환하면서 기술 아키텍처뿐 아니라 프로젝트를 다루는 일상적인 방식도 달라졌습니다.

최종 결론이 아니라 선택한 방향

현재 이 아키텍처는 DigiMeld 생태계의 상당 부분에서 이미 운영되고 있습니다.

나머지 프로젝트도 새로운 관리자 접근 모델로 차례차례 전환하고 있습니다.

각 애플리케이션의 동작을 확인하며 순차적으로 마이그레이션을 진행하고 있고, 전환을 마친 뒤에는 시스템 전체를 추가로 감사할 계획입니다.

인터페이스의 일부 요소와 세션 관리 규칙은 앞으로 바뀔 수도 있습니다.

하지만 핵심 아이디어는 이미 정해졌습니다.

수십 개의 프로젝트를 관리하기 위해 수십 개의 관리자 비밀번호를 계속 저장하고 사용해야 하는 모델로 돌아가고 싶지 않습니다.

그렇다고 제 구현 방식이 모두를 위한 보편적인 해결책이라고 생각하는 것은 아닙니다.

조직마다 요구 사항과 인프라, 위협 모델, 관리 방식이 다릅니다.

DigiMeld 생태계에 편리하고 타당한 방식이 다른 개발자에게도 최선이라는 보장은 없습니다.

하지만 권한을 일시적으로 부여한다는 원칙은 주목할 만합니다.

맺음말

제가 이 경험을 나누기로 한 것은 새로운 인증 방식을 발명했다고 생각해서가 아닙니다.

또 어떤 시스템을 완벽하게 안전한 것처럼 내세우고 싶어서도 아닙니다.

절대적인 보안은 존재하지 않습니다.

저는 단지 문제를 바라보는 관점 자체가 흥미롭다고 생각합니다.

상시 존재하는 관리자 로그인 경로를 끝없이 보호하는 대신, 그 경로가 꼭 필요한지 다시 생각해 볼 수 있습니다.

수많은 비밀번호를 저장하는 대신 임시 권한을 사용할 수 있습니다.

첫 인증 후 자동으로 신뢰하는 대신, 구체적인 권한을 부여할 때마다 확인할 수 있습니다.

세션이 끝날 때까지 기다리는 대신 접근 권한을 중앙에서 취소할 수 있게 할 수 있습니다.

마지막으로 각 프로젝트마다 별도의 로그인 메커니즘을 두는 대신, 애플리케이션의 독립성을 유지하면서 관리자 접근을 관리하는 통합 시스템을 구축할 수 있습니다.

이런 접근 방식으로 침해 가능성을 완전히 없앨 수 있다고 주장하는 것은 아닙니다.

그저 상시 존재하는 자격 증명을 보호하는 데서, 권한을 통제하며 부여하고 취소하는 데로 초점을 옮기는 것입니다.

때로는 공격 표면을 줄이는 가장 효과적인 방법이 또 다른 보호 장치를 추가하는 것이 아니라, 시스템이 작동하는 데 꼭 필요하지 않은 요소를 없애는 것일지도 모릅니다.

저에게 MeldID Admin Gateway의 이야기는 바로 이 생각에서 시작되었습니다.