‘다중 인가 검증’ 시연 영상
Keycloak을 이용한 Legacy 전자정부 프레임워크 애플리케이션의 '다중 인가 검증' 시연 영상
이번 영상에서는 이전 포스트들에서 언급한 바와 같이 Scope 기반의 Permission이 사용되었습니다.
Scope 기반의 접근제어 또는 Resource-Scope를 이용한 접근 통제 라고 보시면 되겠습니다.
Permission 안에 Resource와 Scope가 모두 적용되니까요.
이전 포스트에 언급되었던 내용보다 약간 기능을 추가한후 시연 영상을 녹화하게 되었습니다.
인가 포인트를 설정하는 방식을 하나 더 추가했기 때문에 조금 늦어졌습니다.
추가하고 보니, 참 잘했다는 생각이 듭니다.
실무에서는 재빌드 / 재배포 또한 번거롭고 업무 부하를 유발하는 요인 일테니까요.
왜 Keycloak-policy-enforcer등의 패키지에서 별도의 설정 파일로 인가 정보를 설정하게 했는지 알것도 같습니다.
네. Best Practice는 벤치마킹하는게 좋다고 생각합니다. policy-enforcer의 외부 파일 설정 방식을 참조했습니다.
이번 영상에서는 두가지 기능을 예시로 시연을 진행했습니다.
'품목상세조회' 화면의 '입찰 대기'와 '바로 입찰' 버튼의 기능을 대상으로 시연했습니다.
겹겹이 계층적으로 동작한다는 것을 시연하기위해, 일부러 차단 정책을 모두 적용하고, 해제하면서 동작을 시연했습니다.
시연 영상처럼, 단계적으로 동작하는 것을 보여주기는 아주 좋은 시나리오입니다만, 실무에서 이처럼 각 계층별로 모두 같은 정책을 적용한다면 심층 방어의 의미가 없다고 생각합니다.
각 Permission(Resource와 Scope의 조합) 별로 각기 다른 기준과 정책으로 사용자 요청을 검증하여, 이전 단계를 우회하고 침투하더라도 다음 단계에서 차단될수 있는 정책의 설정이 매우 중요한 요소라고 생각합니다.
실무에서는 반드시 각기 다른 정책과 기준이 각 단계별로 적용되어야 한다고 생각합니다.
이 중요한 내용이 시연 영상에서는 누락되었네요.
Resource 정보의 Cache 또는 인가 포인트 정보의 Cache를 Refresh하는 Endpoint에 대해 고민한다는 내용을 이전 영상에서 언급한 적이 있습니다. 하지만 아직까지 구현할 계획을 잡지 않고 있습니다.
이유는 '또 다른 케어 포인트의 추가'입니다.
애플리케이션의 재시작에 따른 Downtime을 방지하기 위해 Cache Refresh하는 Endpoint는 무엇으로 보호할수 있을까요?
이번에 소개한 '다중 인가 검증'을 적용하는 것이 나을까요?
만약 작성한다면 Filter나 Controller에 작성되어야 할텐데, 추가적인 코드 침습은 없을까요?
이 기능은 OIDC Template Code-Client가 아닌 Authz의 기능입니다.
이 기능을 추가하기 위해서 추가적인 Filter나 Controller코드의 작성이 필수가 될수 있습니다.
그래서 아직도 고민중입니다.
다음 내용은, OIDC Template Code를 사용하는 목적과 또다른 용도에 대한 것입니다.
이번의 '다중 인가 검증'은, 최신 Keycloak을 이용하여 Legacy Spring / 전자정부 애플리케이션과 연동하고,그 애플리케이션의 보안을 더욱 강화시키는 방향이었다고 생각합니다.
트레이드오프는 있지만요.
다음엔, 최신 Keycloak을 이용하여 왜 Legacy Spring / 전자정부 어플리케이션과 연동하는지, 이 목적에 따른 내용을 소개해드릴까 합니다.
감사합니다
Scope 기반의 접근제어 또는 Resource-Scope를 이용한 접근 통제 라고 보시면 되겠습니다.
Permission 안에 Resource와 Scope가 모두 적용되니까요.
이전 포스트에 언급되었던 내용보다 약간 기능을 추가한후 시연 영상을 녹화하게 되었습니다.
인가 포인트를 설정하는 방식을 하나 더 추가했기 때문에 조금 늦어졌습니다.
추가하고 보니, 참 잘했다는 생각이 듭니다.
실무에서는 재빌드 / 재배포 또한 번거롭고 업무 부하를 유발하는 요인 일테니까요.
왜 Keycloak-policy-enforcer등의 패키지에서 별도의 설정 파일로 인가 정보를 설정하게 했는지 알것도 같습니다.
네. Best Practice는 벤치마킹하는게 좋다고 생각합니다. policy-enforcer의 외부 파일 설정 방식을 참조했습니다.
이번 영상에서는 두가지 기능을 예시로 시연을 진행했습니다.
'품목상세조회' 화면의 '입찰 대기'와 '바로 입찰' 버튼의 기능을 대상으로 시연했습니다.
겹겹이 계층적으로 동작한다는 것을 시연하기위해, 일부러 차단 정책을 모두 적용하고, 해제하면서 동작을 시연했습니다.
시연 영상처럼, 단계적으로 동작하는 것을 보여주기는 아주 좋은 시나리오입니다만, 실무에서 이처럼 각 계층별로 모두 같은 정책을 적용한다면 심층 방어의 의미가 없다고 생각합니다.
각 Permission(Resource와 Scope의 조합) 별로 각기 다른 기준과 정책으로 사용자 요청을 검증하여, 이전 단계를 우회하고 침투하더라도 다음 단계에서 차단될수 있는 정책의 설정이 매우 중요한 요소라고 생각합니다.
실무에서는 반드시 각기 다른 정책과 기준이 각 단계별로 적용되어야 한다고 생각합니다.
이 중요한 내용이 시연 영상에서는 누락되었네요.
Resource 정보의 Cache 또는 인가 포인트 정보의 Cache를 Refresh하는 Endpoint에 대해 고민한다는 내용을 이전 영상에서 언급한 적이 있습니다. 하지만 아직까지 구현할 계획을 잡지 않고 있습니다.
이유는 '또 다른 케어 포인트의 추가'입니다.
애플리케이션의 재시작에 따른 Downtime을 방지하기 위해 Cache Refresh하는 Endpoint는 무엇으로 보호할수 있을까요?
이번에 소개한 '다중 인가 검증'을 적용하는 것이 나을까요?
만약 작성한다면 Filter나 Controller에 작성되어야 할텐데, 추가적인 코드 침습은 없을까요?
이 기능은 OIDC Template Code-Client가 아닌 Authz의 기능입니다.
이 기능을 추가하기 위해서 추가적인 Filter나 Controller코드의 작성이 필수가 될수 있습니다.
그래서 아직도 고민중입니다.
다음 내용은, OIDC Template Code를 사용하는 목적과 또다른 용도에 대한 것입니다.
이번의 '다중 인가 검증'은, 최신 Keycloak을 이용하여 Legacy Spring / 전자정부 애플리케이션과 연동하고,그 애플리케이션의 보안을 더욱 강화시키는 방향이었다고 생각합니다.
트레이드오프는 있지만요.
다음엔, 최신 Keycloak을 이용하여 왜 Legacy Spring / 전자정부 어플리케이션과 연동하는지, 이 목적에 따른 내용을 소개해드릴까 합니다.
감사합니다