개발자를 위한 보안 정복: 공유 및 학습 시리즈 - 잘못된 접근 제어

비즈니스 애플리케이션을 구축할 때는 내부용이든 고객 외부용이든 관계없이 모든 사용자가 모든 기능을 수행하도록 허용하지 않는 것이 일반적입니다. 만약 그렇게 한다면, 접근 제어 취약점(Broken Access Control)에 노출될 위험이 있습니다.

접근 제어 취약점이란 무엇이며, 왜 위험한지, 그리고 이를 어떻게 해결할 수 있는지 살펴보겠습니다.

접근 제어 취약점 이해하기

접근 제어 취약점은 애플리케이션 코드에 적절한 보안 또는 접근 확인 절차가 마련되어 있지 않을 때 발생합니다. 또한 애플리케이션 설정이 잘못되어 사용자가 접근해서는 안 될 기능이나 페이지에 접근할 수 있게 될 때도 발생합니다.

회사의 재무를 담당하는 경우, 특정 계좌에 돈을 입금하거나 회사 계좌 간에 자금을 이체할 권한이 있을 수 있습니다. 하지만 해당 계좌에서 현금을 인출하거나 다른 계좌로 돈을 이체할 권한까지 있어서는 안 됩니다. 적절한 접근 확인 절차가 없다면, 직원들이 필요한 것보다 더 많은 기능을 수행할 수 있게 됩니다.

이러한 확인 절차는 코드 내에서 수행하거나 설정 파일을 통해 처리할 수 있습니다. 예를 들어, 웹 애플리케이션 프레임워크에 어떤 사용자가 어떤 페이지에 접근할 수 있는지 알려주는 XML 설정 파일이 있을 수 있습니다. 이를 통해 사용자는 자신이 권한을 부여받은 기능에만 접근할 수 있게 됩니다.

접근 제어 취약점이 위험한 이유

다음 사례를 생각해 봅시다. 공격자가 사용자 계정 생성 코드를 조작할 수 있다는 사실을 알아내어, 간단한 POST 요청만으로 관리자 계정을 생성할 수 있게 되었습니다. 공격자는 사용자 이름과 비밀번호를 포함한 요청을 보낸 뒤, 전송 과정에서 URL 매개변수나 요청 본문에 관리자 권한을 추가합니다. 공격자가 애플리케이션에 로그인하면 즉시 관리자 권한을 얻게 됩니다.

시스템을 침해하는 것이 항상 악의적인 공격자일 필요는 없습니다. 적절한 접근 제어가 없으면 부서 간에 공유되어서는 안 될 민감한 정보가 유출될 수 있습니다. 만약 회사 내 모든 직원이 인사팀의 급여 데이터나 재무 데이터를 볼 수 있다면 어떨까요? 회사의 재정 상황이 좋지 않아 정리해고가 예정되어 있다는 사실을 모든 직원이 알게 된다면 어떤 일이 벌어질까요? 이는 사기 저하와 기업 평판에 치명적인 영향을 줄 수 있습니다.

고객의 민감한 정보가 유출될 수도 있습니다. 기업은 종종 서비스를 이용하는 고객의 개인정보를 저장합니다. 접근 제어 미비로 인해 이러한 정보가 실수로 노출되지 않도록 주의해야 합니다. 예를 들어, 시스템에서 사용자가 자신의 건강 기록을 요청할 수 있게 되어 있다면, 다른 사람의 건강 정보를 요청하고 볼 수 있는 권한도 함께 부여되지는 않았나요? URL에 고객 ID 번호가 포함되어 있다면, 공격자는 해당 ID 번호를 계속 증가시켜 다른 고객의 정보와 일치하는 번호를 찾아내어 개인정보를 탈취할 수 있습니다.

접근 제어 취약점 방어하기

역할 기반 접근 제어(RBAC)는 견고한 접근 제어를 구현하는 매우 효과적인 도구입니다. Active Directory 사용자는 그룹을 생성하여 개인이 아닌 그룹 단위로 특정 항목에 대한 접근 권한을 부여하는 방식에 익숙할 것입니다. 애플리케이션도 이와 동일한 방식으로, 역할을 사용하여 누가 무엇을 볼 수 있는지 정의합니다.

이 방식에는 두 가지 장점이 있습니다. 첫째, 관리자 역할에서 누군가가 빠지더라도 기능을 변경할 필요가 없습니다. 이전에 관리자였던 사람이 더 이상 관리자가 아니게 되면, 새로운 사람을 관리자 역할에 배치하고 이전 사람을 해당 역할에서 제거하기만 하면 됩니다. 코드는 개별 사용자가 특정 페이지나 기능에 접근할 수 있는지 확인하는 대신, 사용자가 관리자 역할을 가지고 있는지 확인합니다.

두 번째 장점은 유지보수의 악몽을 피할 수 있다는 것입니다. 모든 사람이 모든 가능한 기능이나 페이지와 연결되는 세분화된 접근 제어는 시간이 지날수록 관리가 불가능해집니다. 역할 기반 방식은 여러 사람을 하나의 역할에 추가할 수 있어 훨씬 편리합니다. 한 역할에는 전 직원이 포함될 수 있고, 다른 역할에는 5명만 포함될 수도 있습니다. 관리해야 할 역할의 수가 줄어들기 때문에 역할 관리가 훨씬 효율적입니다. 1만 명 규모의 회사라면 애플리케이션의 기능 수에 1만 명을 곱한 만큼의 권한을 관리하는 대신, 100개의 역할만 관리하면 됩니다. 선택한 애플리케이션 프레임워크에서 강력한 접근 제어를 위해 어떤 옵션을 제공하는지 확인해 보십시오.

기능 수준의 접근 제어를 사용하는 것도 매우 중요합니다. 사용자가 특정 접근 제어 확인 절차를 통과하도록 요구하여 모든 기능에 대한 접근을 보호하십시오. 최소 권한의 원칙을 적용하여 기본적으로 접근을 거부하고 필요한 경우에만 접근을 허용하십시오. 모든 기능에 접근 제어를 구현하는 것을 잊기 쉽습니다. 중앙 집중식 구성 요소를 사용하여 접근 제어를 관리하고 강제하십시오.

민감한 기능 보호하기

접근 제어 취약점은 데이터와 애플리케이션을 공격과 악용에 무방비로 노출시킬 수 있습니다. 제대로 보호되지 않은 고객 데이터는 대규모 데이터 유출로 이어져 기업의 평판과 수익에 큰 타격을 줄 수 있습니다.

잘못된 접근 제어는 공격자가 권한 없는 기능에 접근할 경우 계정 탈취로 이어질 수 있습니다. 적절한 기능 수준의 접근 제어를 구현하여 악의적인 공격자는 물론 내부자의 실수로부터 애플리케이션을 안전하게 보호하세요.

기능 수준의 접근 제어를 완벽하게 이해하셨나요? 지금 바로 잘못된 접근 제어 문제를 해결하는 챌린지에 도전해 보세요: [여기서 시작하기]