도메인 객체의 인스턴스 레벨에서 풍부한 권한 부여를 가능하게 해 주는 접근 제어 목록(Access Control List, ACL)이라는 복잡한 주제에 대해 다루어 본다. 스프링 시큐리티는 중소 규모에 달하는 구현 시스템의 요구사항을 상당 부분 충족시킬 수 있는 접근 제어 목록 모듈을 제공하는데, 이 모듈은 강력한 기능에 비해 복잡하고 문서화가 부족하다는 단점이 있다.
1. 비즈니스 객체 보안과 ACL의 목적
개발자가 웹 티어가 아닌 다른 부분에 보안을 적용할 때 마지막으로 직면하는 보안 적용 조각은 비즈니스 데이터 또는 그 밑단에 있는 비즈니스 객체 자체에 대한 보안이다. 이 레벨에서의 보안은 접근 제어 목록 또는 ACL이라고 부르는 방식으로 구현한다. ACL의 목적은 단일 객체 인스턴스 수준에서 개별 사용자나 그룹이 수행할 수 있는 권한을 정의하는 것이다. 예를 들어 특정 개발자가 자신의 프로필에 쓰기 권한이 가능하도록 설정하는 경우를 떠올려 볼 수 있다.
2. ACL의 핵심 용어와 개념
스프링 시큐리티의 ACL 기능을 설정하기 전에 먼저 핵심이 되는 용어와 개념들을 살펴봐야 한다.
-
보안 식별자(SID): 사용자의 신원을 추상화하는 논리적인 구성 요소이다.
-
객체 식별자(Object Identity): 보호 대상이 되는 객체 자체를 의미한다.
-
접근 규정 항목(ACE): 특정 SID와 객체, 그리고 그 객체에 대해 허용되는 권한의 조합으로 구성되는 실질적인 규칙이다.
3. 데이터베이스 스키마 설계
이러한 ACL 기능을 지원하기 위해서는 데이터베이스 스키마 개발이 필수적이다. 기본적으로 네 가지 핵심 테이블이 사용된다.
-
ACL_SID: 보안 대상의 신원(사용자 또는 역할)을 저장하는 테이블.
-
ACL_CLASS: 보안이 적용되는 도메인 클래스의 완전한 이름(FQCN) 정보를 담는 테이블.
-
ACL_OBJECT_IDENTITY: 특정 객체 인스턴스를 고유하게 정의하는 테이블.
-
ACL_ENTRY: 실질적인 권한 부여 내역(ACE)을 담는 항목 테이블.
데이터베이스 설계 시에는 성능과 호환성을 고려하여 스키마를 구성해야 하며, 오라클이나 포스트그레SQL과 같은 다른 데이터베이스를 사용할 경우 해당 환경에 적합하도록 수정한 SQL을 적용해야 한다.
4. ACL 구성 요소와 최적화 전략
설정 측면에서 보면 ACL 모듈은 스프링 시큐리티 프레임워크의 나머지 부분과 마찬가지로 의존성 주입이 필요한 여러 구성 요소로 나뉜다. 주요 구성 요소로는 데이터베이스에서 ACL 정보를 로드하는 전략 클래스와 권한 부여 결정을 내리는 로직, 그리고 성능 향상을 위한 캐싱 메커니즘 등이 있다.
특히 데이터베이스 조회 성능을 최적화하기 위해 조인 쿼리를 사용하는 전략을 선택하거나, 빈번한 조회를 방지하기 위해 에드캐시(Ehcache) 기반의 캐시 구현체를 사용하는 것이 일반적이다.
5. 메서드 보안 적용과 실행
비즈니스 메서드에 ACL 보안을 적용할 때는 애노테이션과 스프링 빈을 사용한다. 이를 통해 개발자는 메서드 호출 시점에 해당 개발자가 요청한 객체에 대해 적절한 권한을 가지고 있는지 체크할 수 있다. 만약 권한이 없는 개발자가 접근하려고 하면 접근 거부 예외가 발생하여 시스템을 보호하게 된다.
ACL 모듈은 그 자체로 매우 강력하지만 구현이 복잡하고 고려해야 할 사항이 많다. 따라서 개발자는 시스템의 성능에 미치는 영향과 설계상의 고려 사항을 면밀히 검토해야 한다. 이 장에서 다룬 개념적 모델과 데이터베이스 스키마, 그리고 구성 전략들을 잘 이해한다면 보다 정교하고 안전한 보안 시스템을 구축할 수 있을 것이다.