권한을 어떻게 표현하나

기능을 하나 추가할 때마다 if (user.isAdmin())이 코드 여기저기에 늘어난다.

권한 검사가 코드 곳곳에 흩어졌다

서비스가 자라면 대개 이런 코드가 쌓인다.

public void deletePost(Long postId, User user) {
    if (!user.isAdmin() && !"MANAGER".equals(user.getGrade())) {
        throw new AccessDeniedException();
    }
    postRepository.delete(postId);
}

public Report exportReport(User user) {
    if (!user.isAdmin() && user.getDeptCode() != 10) {   // 조건이 조금 다르다
        throw new AccessDeniedException();
    }
    return reportService.build();
}

문제가 하나가 아니다.

• 같은 뜻의 조건이 조금씩 다르게 적혀 있다. isAdmin()과 "MANAGER".equals(...)가 어떤 관계인지 코드만 봐서는 모른다.
• “누가 무엇을 할 수 있나”를 한눈에 볼 수 없다. 물어보려면 코드를 전수 조사해야 한다.
• 정책이 바뀌면 다 찾아 고쳐야 한다. 하나 빠뜨리면 거기만 조용히 뚫린다.

인증은 답이 하나다. “이 요청의 주인은 7번 사용자다.” 인가는 그렇지 않다. 경로마다, 리소스마다, 상황마다 답이 다르다. 그래서 표현할 방법을 정해두지 않으면 이렇게 흩어진다.

이 글은 두 가지를 정한다. 권한을 무엇으로 적을 것인가, 그리고 어디서 검사할 것인가.

권한은 결국 한 문장이다

흩어진 조건들을 정리하려면 먼저 공통 모양을 찾아야 한다. 위 코드들이 실제로 묻는 것은 전부 이 문장이다.

누가(주체) - 무엇을(대상) - 어떻게 할 수 있나(행위)

셋 다 같은 틀이다. 그러면 권한 모델을 고르는 문제는 “이 문장의 주체 자리를 무엇으로 채울 것인가” 로 좁혀진다.

가장 단순한 답은 사용자를 직접 적는 것이다. “7번 사용자는 게시글을 삭제할 수 있다.” 동작은 하지만 금방 무너진다. 사용자가 만 명이면 규칙이 만 줄이 되고, 사람이 들어오고 나갈 때마다 규칙을 손대야 한다.

그래서 사이에 한 겹을 끼운다.

역할로 묶는다

사용자와 권한 사이에 역할(role)을 둔다. 사용자에게 역할을 주고, 권한은 역할에 붙인다. 이 방식을 RBAC(Role-Based Access Control) 라고 부른다.

사람이 늘어도 역할 수는 안 늘어난다. 새 직원이 들어오면 역할 하나만 주면 되고, 정책이 바뀌면 역할에 붙은 권한만 고치면 그 역할을 가진 전원에게 반영된다.

역할과 권한을 나눠 두는 것도 흔하다.

이렇게 두면 “관리자는 무엇을 할 수 있나”가 데이터로 존재한다. 코드를 뒤지지 않고 테이블 하나로 답할 수 있다.

역할이 부족해지는 순간

RBAC로 대부분이 해결된다. 그런데 어느 시점에 딱 막힌다.

“본인이 쓴 글만 수정할 수 있다.”

이 규칙에는 역할이 안 나온다. 김철수가 USER 역할이라는 사실만으로는 판단이 안 된다. 어떤 글을 수정하려는지 알아야 답이 나온다.

두 질문의 성격이 다르다. 앞은 주체만 보면 되고, 뒤는 주체와 대상을 함께 봐야 한다. 이걸 억지로 역할로 풀려고 하면 이상해진다. 글 하나마다 역할을 만들 수는 없다.

같은 성격의 규칙이 실무에 널려 있다.

• 자기 부서의 문서만 조회
• 근무 시간에만 결제 승인
• 결제 금액이 100만 원 미만이면 팀장, 이상이면 임원

전부 요청 시점의 값에 따라 답이 갈린다. 역할은 사람에게 미리 붙여둔 라벨이라 이런 규칙을 담지 못한다.

속성으로 판단한다

그래서 다른 축이 나온다. 미리 붙여둔 라벨 대신 판단 시점의 속성들을 조합해서 결정하는 방식이다. ABAC(Attribute-Based Access Control) 라고 부른다.

앞의 규칙을 이 언어로 다시 쓰면 이렇게 된다.

// "본인 글만 수정" - 주체의 id와 대상의 작성자를 비교한다
public boolean canEdit(User user, Post post) {
    return post.getAuthorId().equals(user.getId())
        || user.hasRole("ADMIN");
}

두 방식이 대립하는 게 아니라는 점이 여기서 드러난다. 위 코드에도 역할 검사가 그대로 들어 있다. 실무에서는 대체로 이렇게 쓴다.

• 경로 단위의 굵은 검사는 역할로. “관리자 화면은 ADMIN만”
• 리소스 단위의 세밀한 검사는 속성으로. “이 글의 작성자거나 관리자”

스코프는 또 다른 축이다

여기에 축이 하나 더 있다. 앞 글에서 본 스코프다.

역할과 속성은 “이 사람이 무엇을 할 수 있나” 를 말한다. 스코프는 “이 사람이 이 앱에 무엇을 위임했나” 를 말한다. 둘은 다른 질문이라 둘 다 통과해야 한다.

예를 보면 명확하다. 어떤 앱이 report:write 스코프로 토큰을 받았다. 그런데 그 토큰의 주인인 김철수는 보고서를 쓸 권한이 없는 일반 사원이다. 그러면 거부해야 한다. 위임은 원래 갖고 있는 권한을 넘어설 수 없다.

반대도 마찬가지다. 김철수가 관리자여도, 그 앱에 report:write를 허락하지 않았다면 그 앱은 못 쓴다.

어디서 검사하나

이제 두 번째 질문이다. 무엇으로 적을지 정했으면, 그 검사를 코드의 어느 층에 둘 것인가.

층은 대체로 셋이다.

길목 - 요청이 애플리케이션에 들어오는 자리에서 경로 단위로 막는다. /admin/**은 ADMIN만, 같은 규칙이다. 여기서 막히면 컨트롤러가 그 요청을 아예 보지 못한다. 이 층이 Middleware 글에서 본 필터 체인이고, 인증이 앞이고 인가가 뒤인 이유도 거기서 나온다. 구현 상세는 그 글이 갖고 있다.

서비스 - 기능 하나를 실행하기 직전에 검사한다. 리소스를 꺼내봐야 판단되는 규칙(“본인 글인가”)은 여기 있어야 한다. 길목에서는 대상이 아직 로딩되지 않았으니 판단할 수가 없다.

데이터 조회 - 목록을 뽑을 때 아예 볼 수 있는 것만 뽑는다. “내 부서 문서만” 같은 규칙은 조회 조건에 넣는 게 맞다. 전부 꺼낸 뒤에 걸러내면 안 되는 이유가 둘이다. 필요 없는 데이터를 읽고, 거르는 코드를 빠뜨리면 그대로 새기 때문이다.

세 층을 어떻게 나눌지는 규칙의 성격이 정한다.

실무에서 정책을 한곳에 모으기

Spring Security는 위 세 층에 각각 자리를 준다.

길목은 설정 한 곳에 모은다.

http.authorizeHttpRequests(reg -> reg
        .requestMatchers("/admin/**").hasRole("ADMIN")
        .requestMatchers(HttpMethod.POST, "/posts/**").hasAuthority("post:write")
        .requestMatchers("/posts/**").permitAll()
        .anyRequest().authenticated());

이 블록 하나가 “어느 경로를 누가 쓸 수 있나”의 목차가 된다. 흩어진 if문과 가장 크게 다른 점이 이것이다. 한 화면 안에서 전체 정책이 읽힌다.

서비스는 애너테이션으로 붙인다.

@PreAuthorize("hasRole('ADMIN') or @postAuth.isAuthor(authentication, #postId)")
public void editPost(Long postId, String content) { ... }

대상을 보고 판단하는 규칙이라 길목에는 둘 수 없는 것들이다.

규칙이 복잡해지면 표현식에 다 적지 말고 판단하는 객체를 따로 만든다.

@Component("postAuth")
public class PostAuthorizer {

    private final PostRepository posts;
    private final UserRepository users;

    public boolean canEdit(Authentication auth, Long postId) {
        Post post = posts.findById(postId);          // 저장된 값을 직접 꺼낸다
        if (hasRole(auth, "ADMIN")) return true;
        if (post.isLocked()) return false;

        Long myId = users.findByUsername(auth.getName()).getId();
        return post.getAuthorId().equals(myId);      // id끼리 비교한다
    }
}

// @PreAuthorize("@postAuth.canEdit(authentication, #postId)")

두 가지를 눈여겨볼 만하다. 판단할 글을 저장소에서 꺼내 온다는 것, 그리고 비교하는 두 값의 타입이 같다는 것이다. authentication.getName()은 대개 로그인 아이디라서, 그걸 숫자 authorId와 바로 견주면 언제나 거짓이 된다. 그러면 권한이 있는 사람도 막히는데, 아무 에러 없이 403만 나와서 원인을 찾기 어렵다.

정책이 자바 코드로 한 곳에 모이니 테스트할 수 있고, 왜 막혔는지 설명할 수 있다. 문자열 표현식에 조건을 계속 붙이다 보면 둘 다 못 하게 된다.

마지막으로 운영에서 자주 밟는 자리 몇 개를 적어둔다.

• hasRole과 hasAuthority를 섞어 쓰는 것. hasRole("ADMIN")은 실제로 ROLE_ADMIN을 찾는다. 권한 문자열을 저장할 때 접두사를 빠뜨리면 조용히 403이 난다.
• 권한을 토큰에 담고 잊는 것. 토큰에 역할을 넣어두면 권한을 회수해도 만료 전까지 반영되지 않는다. 즉시 반영이 필요한 권한이라면 요청 때 조회해야 한다.
• 거부 로그를 안 남기는 것. 403이 났을 때 “누가·무엇을·왜 막혔는지”가 없으면 문의가 들어와도 답할 수가 없다.

정리

이 시리즈는 “너 누구냐”와 “너 그거 해도 되냐”를 갈라놓는 데서 시작했다. 앞의 답을 세션에 둘지 토큰에 둘지 골랐고, 그 답을 남에게 위임하는 방법을 봤고, 마지막으로 뒤의 답을 무엇으로 적고 어디서 검사할지까지 왔다. 두 질문이 갈라진 채로 끝까지 갔다는 것, 그게 이 시리즈가 남기려던 하나다.