Keycloak 시작하기 10

1. Keycloak 보안

이번글에서는 Keycloak 서버 자체를 보호하는 몇가지 중요한 측면을 알아보겠습니다.

[ 보안 배포 예시 ]

 

Keycloak과 해당 데이터베이스는 웹 애플리케이션 방화벽(WAF, Web Application Firewall)을 사용해 사용자 및 애플리케이션으로부터 격리되며 모든 네트워크 요청이 암호화되고 데이터베이스도 암호화됩니다.

Keycloak에 송수신되는 트래픽에 TLS(Transport Layer Security)를 사용해야하는 이유를 먼저 알아보겠습니다.

 

2. Keycloak에 대한 통신 암호화

keycloak과의 통신에는 엔드 투 엔드 암호화 (end-to-end encryption) 사용을 권장합니다. 즉 HTTP가 아닌 HTTPS를 항상  사용해야 합니다. 현재는 HTTPS의 가장 최근 보안 계층은 TLS 1.3이므로 가능하다면 해당 버전 사용을 권장합니다. 대부분의 HTTP 라이브러리는 최소 TLS 1.2를 지원합니다. TLS 1.2는 2008년부터 사용해왔기 떄문에 HTTPS 라이브러리가 TLS1.2를 지원하지 않는 경우 해당 라이브러리를 사용하지 않는 것을 고려해야합니다.

 로드 밸런서 똔느 리버스 프록시를 Keycloak 앞단에 사용하고 있는 경우 가장안전한 접근 방식은 클라이언트와  Keycloak간에 엔드 투 엔드 암호화를 제공하는 TLS 패스스루(passthrough)를 활용하는 것입니다.

상황에 따라 TLS 패스스루 사용이 어려울 수 있습니다. 이러한 경우 내부 인증서를 통해 프록시와 Keycloak간의 통신을 다시 암호화할 수 있습니다.

프록시와 Keycloak간에 암호화되지 않은 통신은 권장하지 않으며, 프록시와 Keycloak이 동일한 시스템에 있는 경우와 같이 프록시와 keycloak이 포함된 네트워크를 완전히 격리할 수 있는 경우에만 암호화되지 않은 통신을 고려할 수 있습니다.

 

3. Keycloak 호스트 이름 설정

Keycloak은 사용자에게 이메일을 전송하는 것과 같이 다양한 이유로 호스트 이름을 알아야 합니다. 일반적으로 Keycloak은 클라이언트가 전송한 Host HTTP 헤더를 통해 호스트이름을 확인합니다. 해당 설정은 공격자가 헤더에 다른 값을 사용해 Keycloak에 요청을 전송할 수 있기 떄문에 프로덕션 환경에서 사용하면 안됩니다.

이와 관련된 공격은 공격자가 Keycloak의 패스워드 복구 기능을 통해 호스트 헤더를 변경해 공격자가 제어할 수 있는 사이트에 대한 링크가 포함된 이메일을 사용자에게 전송하는 경우입니다. 사용자가 URL을 확인하지 않으면 공격자는 패스워드를 업데이트하기 위한 요청을 중간에서 가로챌 수 있습니다. 요청 가로채기를 통해 공격자는 업데이트된 암호를 획득하거나 다른 패스워들르 설정할 수 있습니다. 두 경우 모두 공격자는 사용자 계정에 대한 접근 권한을 얻습니다. 

이러한 유형의 공격을 방어하려면 Keycloak에 대한 고정 호스트 이름을 설정하거나 Keycloak이 역뱡향 프록시를 사용하는 경우 역방향 프록시에서 호스트 헤더를 확인할 수 있습니다. 

Keycloak에 고정 호스트네임을 설정하는 것이 가장 간단하고 안전한 접근 방법입니다. 

 

4. Keycloak에서 사용하는 서명키 순한

모든 서명 및 패스워드 키를 주기적으로 순환하는 것을 권장합니다. 한단에 한번 정도 자주 수행하는 것이 좋습니다. 

다행히 Keycloak은 중단없이 원활하게 키를 순환시킬 수 있도록 해줍니다. 신규 키를 활성화할 수 있으며 기존키는 여전히 토큰을 계속해서 검증할 수 있기 때문입니다.

키 순환은 다음과 같은 몇가지 이점을 제공합니다.

- 특정 키로 서명되거나 암호화된 컨텐츠의 양을 줄입니다.

- 키를 획득하려는 모든 사용자가 사용할 수 있는 시간을 줄입니다.

- 사용자 세션 제한 시간 설정에 관계없이 사용되지 않은 리프레시 토큰 또는 만료 시간이 긴 접근 토큰을 정리합니다. 

 - 공격자가 키에 접근할 수 있거나 최악의 상황에서 키가 유출된 경우 영향을 줄일 수 있습니다.

 

Keycloak에서 서명 키를 순환하려면 브라우저에서 관리자 콘솔에 접속해야합니다. 키를 순환하고자 하는 realm을 선택하고 Realm Settings로 이동한 다음 Keys를 클릭합니다. 

 

realm에서 활성화된 서명 키 목록을 확인할 수 있습니다. Keycloak의 키는 3개의 다른 상태를 가집니다.

 - Active : 활성화 키는 신규 토큰에 서명하는데 사용되며, 우선 순위가 가장 높은 키는 특정 알고리즘에 사용됩니다.

 - Passive : 수동키는 신규 토큰 서명에 사용되지 않지만 이전에 서명된 토큰을 검증하기 위해 사용됩니다.

 - Disabled : 비활성화된 키는 현재 사용하지 않는 키입니다.

 

키를 순환하기 위한 첫번째 단계는 신규 활성화 키를 생성하는 것입니다. 신규 활성화 키를 생성한 후 이전 키가 비활성화되면 모든 활성 사용자 세션 및 토큰이 폐기됩니다. 이 방법은 키 유출이 의심되는 경우에만 사용해야 합니다. 그 외의 경우에는 기존키를 삭제하기 전에 모든 사용자 세션과 토큰이 신규 서명키로 업데이트되도록 일정 기간 동안 기존 키를 비활성화하는 것이 좋습니다. 

신규 키를 생성하려면 추가적인 키 제공자를 사용해야합니다. Add Providers 탭> Add provider 버튼 클릭합니다. 

 

 

하단의 rsa-generated를 선택합니다. 

 

Save 버튼을 눌러 키를 생성합니다.

 

Key Active List를 보면 신규 생성된 키가 가장 높은 우선순위를 갖고 있기 때문에 신규 토큰을 서명하는데 사용됩니다.

 

Keycloak은 자동으로 쿠키와 토큰을 신규 키로 재서명하며 해당 작업은 사용자와 애플리케이션에 영향을 주지않습니다. 

Keycloak은 기본적으로 개인키를 데이터베이스에 저장합니다 적절한 데이터베이스 보안과 주기적인 키 순환을 사용하는 것이 가장 보편적입니다.

추가적인 보안기능으로 Keycloak은 외부 저장소에 키를 저장할 수 있습니다. Keycloak은 자바 키 저장소에서 키를 로드할 수 있습니다. 키에 대한 사용자 정의 소스를 구현할 수 있는 확장 메커니즘이 있습니다. 

최고 수준의 보안을 위해 토큰 서명에 HSM(Hardware Security Module)과 같은 외부 서비스를 사용하는 것도 고려할 수 있습니다. 기본적으로 Keycloak은 현재 이러한 통합을 지원하지 않지만 사용자 정의 제공자를 직접 개발할 수 있는 확장 포인트를 가집니다.

 

5. 주기적인 Keycloak 업데이트

잠재적으로 공격자의 가장 좋은 동기 중 하나는 패치되지 않은 소프트웨어의 알려진 취약점에서 비롯됩니다. Keycloak 또는 운영체제를 주기적으로 업데이트하지 않으면 공격 가능한 패치되지 않은 알려진 취약점 리스트가 점점 더 늘어나게 됩니다. 신규 릴리스를 발견하고 신속하게 업데이트할 수 있는 프로세스를 갖추는 것이 특히 중요합니다. 

여기서 주의할 점은 Keycloak에는 장기간 지원되는 버전이 없다는 점입니다. 그 대신 지속적인 배포 모델, 또는 롤링 릴리스를 활용합니다. 이슈가 발생한 경우 Keycloak을 지속적으로 업데이트하면 변경 사항이 상당히 적기 떄문에 한번에 바이트 크기의 청크를 처리하게 됩니다.

지속적인 릴리스를 사용하려면 대부분의 경우 업데이트 프로세스를 자동화하고 업그레이드가 프로덕션 시스템에 영향을 미치는지 여부를 신속하게 테스트할 수 있어야합니다.

장기간 지원되는 버전을 선호하는 경우 레드햇은 Keycloak의 장기 지원 버전인 Red Hat Single Sign-On을 제공합니다.

 

6. 외부 저장소 시크릿을 Keycloak으로 다운로드

이메일 서버에 접속하거나 디렉터리 서버에서 사용자를 연동하는 것과 같이 외부 시스템에 접근하기 위해 Keycloak에 자격증명을 제공해야 하는 몇가지 사용 사례가 있습니다.

Keycloak은 기본적으로 자격증명을 데이터베이스에 저장하지만 외부 저장소에서 자격증명을 가져올 수도 있습니다. 

Keycloak은 외부 저장소와 통합할 수 있는 확장 메커니즘을 갖고 있습니다. 저장소 설정에 대한 자세한 정보는 Keycloak 서버 관리자 가이드를 참조하면 됩니다. https://www.keycloak.org/docs/latest/server_admin/index.html#_vault-administration

Server Administration Guide

 

7. 방화벽 및 침입 방지 시스템을 통한 Keycloak 보안 

최소한 방화벽을 활용해 Keycloak에 송수신 트래픽을 제어하는 것을 권장합니다. 가능하면 Keycloak 및 데이터베이스를 내부 애플리케이션과 완전히 분리하는 것도 고려해야합니다.

수신되는 트래픽의 경우 , HTTPS 트래픽만 허용하는 제한된 수신 트래픽 정책이 포함됩니다. 또한 Keycloak 관리자 콘솔 및 관리자 REST API 에 대한 접근을 내부 네트워크에서만 허용하는 것을 고려할 수 있습니다. 

송신 트래픽의 경우 , 사용자 환경에 따라 조금 더 까다로울 수 있습니다. 허용해야 하는 트래픽은 다음과 같습니다.

 - 로그아웃 요청과 같은 애플리케이션에 대한 HTTPS 백채널 요청

 - LDAP과 같은 사용자 연동 제공자에 대한 연경

 - OpenID 토큰 요청과 같은 외부 ID 제공자에 대한 백채널 요청

 

Keycloak을 사용해 내부 애플리케이션만 보호하는 경우 송신 트래픽을 보호하는 것이 더 간단할 수 있지만 네트워크 외부에 배포된 서드파티 애플리케이션도 보호해야  하는 경우 작업이 더 어려울 수 있습니다.

또한 침입 방지 시스템을 활용하는 것이 현명한 결정일 수 있습니다. 침입 방지 시스템은 서비스 거부 공격에 대응하는 데 도움을 주며 비정상적인 트래픽을 탐지하고 차단하는데 유용한 도구입니다. 

추가적인 보안을 고려하는 경우 , WAF(Web Application Firewall)를 활용하는 것도 좋은 방법이 될수 있습니다. WAF를 적절하게 설정하는 것은 상대적으로 복잡하고 주기적으로 업데이트를 수행해야 할 수도 있지만 해당 작업을 적절히 수행하는 경우 WAF는 공격에 대한 추가 보호 계층을 제공할 수 있습니다. 

 

8. 데이터베이스 보안

Keycloak은 여러 가지 민감한 데이터를 자체 데이터베이스에 저장하기 떄문에 해당 데이터베이스는 안전하게 유지해야 하며, 공격자가 데이터베이스 접근하거나 수정하는 것을 방지해야합니다.

Keycloak이 데이터베이스에 저장하는 데이터 예시는 다음과 같습니다. 

- Realm 설정

 - 사용자

 - 클라이언트

 

데이터베이스에 보안 침해 사고가 발생해 공격자가 Keycloak 데이터에 접근할 수 있는 경우 발생할 수 있는 몇가지 상황은 다음과 같습니다. 

 - 공격자는 직원이나 고객에 대한 세부 정보에 접근할 수 있습니다. 해당 접근에 대한 영향은 저장된 개인 정보의 양에 따라 다르지만 공격자는 이메일 주소 리스트를 확보한 것만으로 충분할 수 있습니다. 

 - 공격자는 사용자 자격증명에 접근할 수 있습니다. 패스워드는 데이터베이스에 단방향 해시로 저장되지만 공격자는 보안 수준이 낮은 패스워드 중 일부를 크랙할 수 있습니다. 

- 외부 및 키 저장소를 사용하는 경우 공격자는 데이터베이스에 저장된 시크릿(LDAP 연동 자격증명, SMTP 패스워드, Keycloak에서 사용되는 사설 서명키)에 접근할 수 있습니다.

 

위의 내용은 몇가지 예시에 불과하지만 공격자는 일반적으로 매우 창의적이며 데이터를 악용할 모든 종류의 방법을 고안할 수 있습니다.

여기서 강조해야할 중요한 점은 공격자가 데이터베이스에 직접 데이터를 가져오는 지 또는 데이터베이스 백업에서 데이터를 가져오는지 여부에 관계없이 데이터베이스 자체의 보안을 유지하는 것만큼이나 데이터베이스 백업을 보호하는것이 중요하다는 것입니다. 

공격자가 데이터베이스의 쓰기 접근 권한을 획득하면 Keycloak에 의해 보호되는 모든 애플리케이션에 접근할 수 있기 때문에 잠재적으로 상황이 더 악화될 수 있습니다. 즉 사용자의 자격증명을 도용하기 위해 realm 설정 또는 사용자 자격증명을 변경할 수 있습니다. 

 

9. 방화벽을 사용한 데이터베이스 보안

데이터베이스를 보호할 때 가장 먼저 해야할 일은 방화벽으로 데이터베이스를 보호하는 것입니다. 모든 트래픽은 기본적으로 차단해야하고, Keycloak 서버와 같은 필수적인 접근만 허용해야합니다. 또한 뚜렷한 이유가 없는한 아웃바운드 연결은 차단해야 합니다.

 

10. 데이터베이스 인증 및 접근 제어 활성화 

가능한 한 최소한의 사용자만 데이터베이스에 접근할 수 있어야 하며 , 작업을 수행하는데 필요한 최소한의 접근 권한만 가져야합니다. 

Keycloak은 데이터베이스의 데이터와 스키마를 관리하기 떄문에 데이터베이스에 영구적인 접근 권한이 필요한 사람이 있는지 확인할 필요가 있씁니다. 

Keycloak과 데이터베이스에 접근할 수 있는 모든 사용자는 강력한 암호를 사용해야 하며 로그인 시도가 실패하면 해당 계정을 중지시켜야합니다. 클라이언트 인증서와 같은 더 강력한 인증 메커니즘을 활용을 고려할 수 있습니다. 

데이터베이스 접근 제어를 설정한 다음 암호화를 통해 전송 중인 데이터와 저장된 데이터를 보호해야 합니다. 

 

11. 데이터베이스 암호화

전송 중인 데이터를 보호하려면 TLS를 사용해 데이터베이스에 대한 모든 연결을 암호화해야합니다.

데이터베이스가 실행 중인 서버에 불법적인 접근이 발생할 수 있기 떄문에 저장된 데이터를 보호하는 것이 중요하며 데이터베이스 백업 또한 암호화해야합니다. 

데이터베이스를 적절하게 보호하기 위한 다양한 단계가 있으며 , Keycloak을 주기적으로 업데이트하는 것처럼 데이터베이스도 주기적으로 업데이트해야합니다. 

기업이 자체 데이터 센터를 소유한 경우 해당 작업을 수행할 수 있는 직원이 이미 있을 가능성이 높습니다. 그렇지 않은 경우 클라우드의 관계형 데이터베이스 서비스 활용을 고려할 수 있습니다. 

 

12. 클러스터 통신 보안

Keycloak에는 Keycloak 노드 클러스터를 생성할 때 활용되는 Infinispan이 포함돼 있습니다. 데이터베이스와 다르게 Keycloak은 대부분의 민감한 정보를 로컬 캐시에 저장하는 클러스터를 통해 민감한 정보를 전송하지 않으므로, 무효화를 위해서만 클러스터 통신을 활용합니다. Keycloak은 클러스터 전체에 분산된 클러스터의 사용자 세션에 대한 정보를 저장합니다. 세션 자체에는 세션 ID, 만료 날짜 및 연동된 클러이언트 세션과 같은 일부 정보가 포함됩니다. 공격자가 해당 정보에 대한 접근 권한을 획득해도 Keycloak을 통해 세션에 접근하려면 Keycloak에서 서명한 토큰이나 쿠키가 필요하기 때문에 공격 범위를 제한할 수 있습니다. 

적어도 방화벽을 사용해 클러스터 통신을 보호하는 것이 권장됩니다. 그 밖의 추가적인 보안을 위해서 클러스터 통신에 대한 인증 및 암호화를 활성화할 수 있습니다. 

 

클러스터 인증을 활성화하면 인증되지 않은 노드가 클러스터에 포함되는 것을 방지 할 수 있습니다. 하지만 클러스터 멤버와 비멤버 간의 통신을 방지할 수는 없습니다 따라서 단순히 인증만 추가하는 것은 거의 이미가 없으며, 인증은 비대칭 암호화와 통합해야합니다.

 

클러스터 통신은 공유 키를 사용하는 대칭 암호화를 사용하거나 인증과 통합된 비대칭 암호화를 사용해 암호화할 수 있습니다. 가장 단순한 접근 방식은 대칭 암호화를 활성화하는 것이므로 해당 암호화를 활성화하는 방법에 대해 알아볼 것입니다. 

첫번째 단계는 공유 시크릿을 저장하는 자바 키 저장소를 생성하는 것입니다. 키 저장소를 생성하려면 터미널에서 다음 명령어를 실행합니다. 

 

13. 사용자 계정 보안

사용자 계정 보안과 관련해 공격자가 사용자 계정에 접근하는 것을 보호해야하며 패스워드를 포함해 사용자에 관한 정보도 보호해야 합니다. 

공격자로부터 사용자 계정을 보호하는 것은 단순히 패스워드를 인증 방법으로 사용하는 것이 아니라 강력한 인증을 통해서만 가능합니다. 사용자가 패스워드를 이중 인증 요소와 함께 사용중이더라도 패스워드를 보호하는 것이 중요합니다. 

패스워드는 강력한 패스워드 해싱 알고리즘 , 적절한 패스워드 정책 그리고 패스워드 무차별 대입 공격 보호 기능 활성화를 통해 보호돼야합니다. 또한 강력한 패스워드 정책과 다른곳에서 사용중인 패스워드를 재사용하지 않도록 사용자를 교육하는 것도 중요합니다.

패스워드 정책을 설정하려면 Keycloak 관리자 콘솔을 열고 설정하고자 하는 realm을 선택합니다. 그다음 Authentication을 클릭한 다음 Policies 탭을 선택 >  Password Policy탭을 선택합니다. 

 

Add policy 버튼을 클릭하여 사용할 정책을 선택하면 패스워드 정책을 선택할 수 있습니다. 

 

아래의 예시는 최소길이가 8자이고 하나 이상의 대문자 , 하나 이상의 소문자, 하나 이상의 특수문자 및 숫자를 포함하는 패스워드 정책 예시입니다. 

 

 

또한 패스워드 무차별 대입 공격 보호 기능을 활성화하는 것을 권장합니다. 

Realm settings 좌측 메뉴 클릭 > Security defenses 탭 클릭 > Brute force detection 탭을 클릭합니다. 

 

Brute Force Protection의 Lockout Mode 종류

Lockout Mode	설명	특징
Lockout permanently	로그인 실패 횟수를 초과하면 계정이 영구적으로 차단됨	관리자가 직접 차단 해제해야 함
Lockout temporarily	로그인 실패 횟수를 초과하면 계정이 일정 시간 동안 차단됨	시간이 지나면 자동으로 차단 해제
Lockout permanently after temporary lockout	일정 횟수까지는 일시적 차단, 그러나 일정 횟수를 넘으면 영구 차단됨	공격 가능성을 점진적으로 줄임

 

사용자 환경에 따라 사용자와 관련된 다양한 수준의 데이터 또는 개인 식별 정보를 저장할 수 있습니다. 개인 정보 처리와 관련돼 취할 수 있는 몇가지 단계는 다음과 같습니다.

 - 반드시 필요한 사용자 정보만 저장

 - 애플리케이션에 노출되는 사용자 정보 제한

 - 데이터베이스 보안

 - 비즈니스를 운영하는 지역의 개인 정보 관련 법률에 대한 이해

 

개인정보취급을 가볍게 여겨서는 안됩니다. 개인 정보는 공격자에게 매우 중요하며 그자체로 판매될 수 있는 상품입니다. 이러한 정보가 유출되면 마갣한 벌금이 부과될 수 있으며 최악의 경우 비즈니스에 돌이킬수 없는 피해를 입힐 수 있습니다. 

 

14. 애플리케이션 보안

많은 애플리케이션이 인터넷에 노출되고 있기 때문에 공격 및 데이터 침해 사고 건수가 날로 증가하고 있습니다. 따라서 애프리케이션을 적절하게 보호해야합니다.

최근까지 공격에 대한 일반적인 대응 방법으로 방화벽과 VPS를 주요 보안 계층으로 활용해왔습니다. 이는 기업 환경의 경계 내에서 의심스러운 보안과 결함됐습니다. 더많은 직원이 재택 근무를 하고 개인 노트북이나 휴대폰을 사용함에 따라 이러한 상황은 점점 더 어려워지고 있습니다. 점점 더 많은 서비스가 파트너 또는 인터넷에 노출되고 있으며 기업 네트워크의 경계를 모호하게 만듭니다. 내부에 존재하는 것을 신뢰하고 외부에 있는 것은 신뢰하지 않는다는 아이디어는 공격자가 엔터프라이즈 네트워크 내부로 침투할 수 있는 다양한 방법이 있고, 내부 공격에 대한 보안 강도가 낮기 때문에 다소 신뢰성이 낮습니다. 

기본적으로 방화벽보다 더 나은것이 필요합니다. Keycloak은 애플리케이션의 보안을 강화할 수 있는 훌륭한 툴이지만, 단순히 keycloak을 사용한다고 해서 애플리케이션이 안전해지진 않습니다. 

 

웹 애플리케이션 보안과 관련된 몇몇 단계는 다음과 같습니다.

 - 인증 : 사용자가 인증되고 세션이 생성되면 세션도 안전하게 보호돼야 한다.

 - 인가 : 최소 권한 접근은 준수할 필요가 있는 훌륭한 원칙이다.작업을 수행하기 위해 사용자에게 부여된 접근 권한을 제한해 위협에 노출된 계정이나 악의적인 직원의 영향을 줄일 수 있다.

 - 범용적인 공격 이해 및 방어 : 인젝션 공격 및 XSS(Cross-Site Scriping)와 같은 범용적인 취약점을 활용한 공격으로부터 애플리케이션을 보호해야한다.

 - 주기적 업데이트 : 웹 애플리케이션 보안은 지속적인 노력이며, 애플리케이션의 보안을 향상시키기 위해 끊임없이 노력해야한다. 또한 프레임워크, 라이브러리 및 사용 중인 모든 도구를 주기적으로 업데이트해야한다.

 - 데이터 보안 : 민감한 데이터는 암호화해서 저장돼야 하며 전송 중인 데이터는 암호화돼야 한다. 백업 데이터 또한 암호화돼야 한다. 웹 애플리케이션과 마찬가지로 데이터 보안 또한 적절한 인증 및 인가 시스템을 갖고 있어야한다.

 - 로깅 및 모니터링 : 적절한 로깅 및 모니터링을 수행하지 않으면 보안 침해 발생을 식별할 수 없다. 로깅 및 모니터링은 진행 중인 공격으로 인한 더 큰 피해를 방지 할 수 있는 유용한 도구가 될수도 있다.

 - 방화벽 : 방화벽과 웹 방화벽은 웹 애플리케이션에 추가적인 보안 계층을 형성한다. 보안을 웹 애플리케이션 방화벽에만 의존하는 것은 권장하지 않으며 애플리케이션 자체에 보안을 구축해야 한다.

 

웹 애플리케이션 보안에 더 자세히 학습할 수 있는 자료는 OWASP(Open Web Application Security Project) Top 10입니다. OWASP Top 10은 웹 애플리케이션에 대한 가장 중요한 보안 위협리스트입니다. 각 위협에 대해 취약점에 관한 세부 설명과 애플리케이션을 보호하는 방법에 대한 팁을 제공합니다.

또 다른 훌륭한 리소스는 애플리케이션 보안의 특정 영역에 대한 매우 간결한 정보가 포함된 여러 치트 시트(Cheat Sheet)를 제공하는 OWASP 치트 시트 시리즈입니다.

 

15. OAuth2.0 및 OpenID 커넥트 베스트 프랙티스

애플리케이션에서 OAuth2.0과 OpenID 커넥트를 사용할 때 실수할 수 있는 부분이 많습니다. OAuth2.0 및 OpenID 커넥트 사용 방법에 대한 사양 자체는 매우 유연하며, 범용적인 취약점에 대응하기 위한 메커니즘은 옵션을 제공합니다.

예를 들어 다음과 같은 인가 요청을 확인할 수 있습니다.

/auth?response_type=code&client_id=public-client&redirect_uri=https://example.com/myclient

 

해당요청에는 상태state 파라미터가 포함돼 있지 않습니다. PKCE도 사용되지 않습니다. 인가 서버에서 해당 파라미터들을 명시적으로 요청하지 않는 한 , 인가 요청은 아무런 문제가 없지만 일부 범용적인 취약점에 노출됩니다.

JWT 사양에도 동일한 상황이 적용됩니다. 비교적 실수가 발생하기 쉽습니다. 한가지 예시는 사야에 포함된 none 알고리즘입니다. 해당 사양에는 유효한 토큰을 서명 알고리즘이 없이 사용할 수 있도록 명시하고 있으며 이러한 사실은 공격자가 악의적인 토큰을 쉽게 생성할 수 있음을 의미합니다. 

보안과 관련된 또 다른 중요한 작업이 FAPI(Financilal-Grade API) 워킹 그룹에서 진행되고 있습니다. 해당 워킹 그룹은 OIDC를 오픈 뱅킹에 활용하기 위해 OIDC의 매우 안전한 프로파일을 구축하는 것에서부터 시작됐습니다. 하지만 추가 보안이 필요한 OIDC의 모든 사용 사례에 해당 워킹 그룹이 생성한 프로파일을 적용할 수 있기 떄문에 이름에 지나치게 구애받을 필요가 없습니다. 해당 프로파일에 포함된 가장 중요한 내용은 베스트 프랙티스를 제공하는 2개의 OIDC 프로파일입니다.

- FAPI 1.0 - Part 1 : API 보안 프로파일 기준

- FAPI 1.0 - Part 2 : 개선된 보안 프로파일

 

위 프로파일들은 베스트 프렉티스 적용의 복잡성과 요구되는 보안 수준과의 균형을 유지할 수 있으며 필요한 사용 사례에 맞게 프로파일을 적용할 수 있습니다.

Keycloak 팀은 또한 클라이언트 정책이라는 기능 생성을 통해 애플리케이션에서 OAuth2.0 및 OpenID Connect의 안전한 사용 방법을 좀 더 쉽게 적용할 수 있도록 큰 진전을 이루고 있습니다. 클라이언트 정책을 통해 필요한 보안 수준에 따라 다양한 애플리케이션에 대해 서로 다른 프로파일을 선택할 수 있으며, 애플리케이션에 대한 베스트 프랙티스를 쉽게 수행할 수 있습니다. 

 

16. Keycloak 클라이언트 설정

보안에 영향을 줄 수 있는 Keycloak OIDC 클라이언트에서 사용할 수 있는 몇몇 설정 옵션에 대해 알아보겠습니다.

 

클라이언트 설정을 검토하고 어떤 것이 보안과 더 관련됐는지 알아보겠습니다.

- Consent required : 해당 옵션은 클라이언트 애플리케이션이 사용자의 데이터를 요청할 때, 사용자가 사전에 이를 확인하고 승인할 수 있게 해주는 보안 및 개인정보 보호 기능입니다. 이 옵션을 활성화 하지 않으면 사용자는 애플리케이션에 설정된 접근 수준을 볼 수 없습니다. 서드파티 애플리케이션을 대상으로 해당 옵션을 활성화 해야합니다. 또한 CLI와 같은 네이티브 애플리케이션에도 이 옵션을 활성화 해야합니다. 즉 , 클라이언트(애플리케이션)가 사용자 정보를 요청할 때, 사용자가 그 정보 제공에 대해 명시적으로 동의하도록 요구하는 기능입니다.

- Client authentication  : 클라이언트 자격증명을 서버 측에서 안전하게 보관할 수 있는 경우 해당 설정을 활성화하는 것이 더 안전합니다. 해당 옵션은 OIDC 클라이언트의 유형을 정의합니다. 이 옵션을 활성화하면, OIDC 유형이 Confidential 접근 유형(비공개 접근 유형)으로 설정됩니다. 비활성화되면 Public 클라이언트 (공개 접근 유형)으로 설정됩니다.

 

• Confidential 클라이언트:
  서버 사이드 애플리케이션과 같이 보안이 중요한 경우 사용됩니다.
  • 클라이언트는 토큰 요청 시 반드시 클라이언트 시크릿(또는 JWT 서명 등)을 사용하여 인증해야 합니다.
• Public 클라이언트:
  브라우저나 모바일 애플리케이션처럼 클라이언트 시크릿을 안전하게 보관할 수 없는 경우 사용됩니다.
  • 이 경우, 클라이언트 인증이 비활성화되어 별도의 인증 정보를 요구하지 않습니다.

 - Standard Flow  :  해당 옵션은 OAuth 2.0의 인가 코드 흐름(Authorization Code Flow)를 사용하도록 클라이언트를 구성하는 설정입니다. 인가 코드 흐름은 사용자가 Keycloak 로그인 페이지에서 인증을 완료한 후, 인가 코드를 클라이언트 애플리케이션으로 리다이렉트시켜줍니다. 클라이언트는 이 코드를 백엔드 서버에서 안전하게 액세스 토큰과 교환하게 됩니다. Standard flow 옵션은 액세스 토큰이 직접 브라우저에 노출되지 않고, 서버 측에서만 처리되기 때문에 보안성이 높습니다. 이는 민감한 정보 보호가 필요한 서버 기반 애플리케이션에 적합합니다

 관리 콘솔에서 클라이언트를 설정할 때, Standard flow 옵션을 활성화하면 해당 클라이언트는 인증 코드 기반의 표준 흐름을 사용하게 됩니다. 비활성화할 경우 다른 흐름(예: implicit flow 등)을 사용하도록 구성할 수 있습니다.

 -  Implicit flow : 해당 옵션은 OpenID Connect의 Implicit Flow 인증 방식을 활성화하는 설정입니다. 이 옵션이 활성화되면, 사용자가 인증을 완료한 후 인가 코드 교환 절차 없이 바로 액세스 토큰과 ID 토큰이 클라이언트의 리다이렉트 URI로 전달됩니다. 사용자가 로그인하면 별도의 백엔드 코드 교환 과정 없이 클라이언트 애플리케이션으로 토큰이 직접 반환됩니다. Implicit Flow는 서버 측 컴포넌트 없이 클라이언트에서 직접 토큰을 수신하는 웹 애플리케이션(예: SPA)이나 모바일 애플리케이션에서 주로 사용됩니다.토큰이 브라우저에 직접 노출되기 때문에, 보안 위험이 상대적으로 클 수 있습니다. 이러한 이유로 최신 권장 방식은 추가 보안 기능(PKCE)을 사용하는 Authorization Code Flow입니다.

이와 같이, Implicit flow 옵션은 클라이언트 애플리케이션이 인증 후 토큰을 바로 받을 수 있도록 설정하지만, 보안 측면에서는 신중하게 사용해야 합니다. (비활성화 권장)

- Direct access grants : 클라이언트가 사용자의 사용자 이름과 비밀번호에 접근하여 이를 Keycloak 서버와 직접 교환하여 액세스 토큰을 받는 방식입니다. OAuth2 사양에 따르면, 이는 이 클라이언트에 리소스 소유자 비밀번호 크레딧  'Resource Owner Password Credentials Grant' 지원을 가능하게 합니다. 주로 신뢰할 수 있는 서버 측 애플리케이션이나 백엔드 서비스에서 사용됩니다. 사용자 자격 증명이 클라이언트에 직접 전달되므로, 보안에 취약할 수 있어 사용 시 주의가 필요합니다. (비활성화 권장)

- Valid redirect URIs : 해당 옵션은 Keycloak 클라이언트 설정에서 인증 후 사용자를 리다이렉션할 수 있는 허용된 URI(엔드포인트)를 지정하는 기능입니다. 리다이렉트 URI와 정확히 일치하는 URI를 사용해야됩니다. 권장되는 URI 예시는 해당 링크와 같습니다. (https://your-app-domain.com/myclient/auth/callback) Keycloak은 모든 리다이렉트 URI에 와일드카드를 지원합니다.  와일드 카드를 사용해야 하는 경우에는 다음 링크  (https://your-app-domain.com/myclient/*)  와 같이 애플리케이션에서 사용할 수 있는 URI 요청으로 제한해야합니다.인증 및 토큰 발급 후, 민감한 정보(예: 인증 코드, 액세스 토큰)가 악의적인 사이트로 전송되는 것을 방지합니다.등록된 URI 외의 주소로 리다이렉션이 시도되면 요청이 거부되어 보안 위협을 줄입니다.

 

이번에는 Keycloak에서 지원하는 몇몇 서명 알고리즘을 알아보겠습니다.

 - Reivset-Shamir-Adleman(RSA) 서명 : Keycloak에서 지원하는 기본 알고리즘입니다. 가장 안전한 옵션은 아니지만 가장 널리 사용되는 옵션이므로 기본값으로 사용됩니다. RSA 서명은 공개키 암호체계인 RSA 알고리즘을 기반으로 한 디지털 서명 방식입니다. 이 서명 방식은 데이터의 무결성과 인증, 부인방지(Non-repudiation)를 보장하기 위해 사용됩니다.

또한 데이터의 안전한 전송 및 인증을 위한 중요한 도구로 활용되며, 다양한 보안 애플리케이션 및 프로토콜에서 널리 사용되고 있습니다.

- ECDSA(Elliptic Curve Digital Signature Algorithm) :  타원 곡선 암호학을 기반으로 한 디지털 서명 알고리즘입니다. 이는 RSA와 같은 전통적인 서명 방식보다 훨씬 짧은 키 길이로도 동일하거나 더 강력한 보안을 제공하여, 저장 공간 및 연산 자원이 제한된 환경에서도 효과적으로 사용됩니다.

 - Hash-based Message Authentication Code(HMAC) : 대칭 키(Shared Secret)에 대한 접근 권한이 필요한 대칭 서명 알고리즘입니다.  데이터의 무결성과 인증을 보장하기 위한 메시지 인증 코드(MAC)를 생성하는 방식입니다. 이는 암호학적 해시 함수와 비밀 키를 결합하여, 전송되는 메시지가 변조되지 않았고, 올바른 발신자에 의해 생성되었음을 검증할 수 있도록 합니다.

 

RSA는 아직까지 안전한 알고리즘으로 고려되지만, 가능하면 RSA 대신 ECDSA를 사용해야합니다. 애플리케이션이 토큰 검사 엔드포인트를 사용해 토큰을 검증하도록 하려면 HMAC을 필수 시크릿으로 사용할 수 있습니다. 해당 설정은 Keycloak에서만 가능합니다. 

또한 다양한 길이의 서명 해시를 선택할 수 있으며, 해시의 길이가 갈수록 더 높은 보안을 제공합니다. 리프레시 토큰 및 접근 토큰과 같이 상대적으로 토큰의 수명이 짧은 토큰의 경우 256비트 길이는 대부분의 사용 사례에서 충분히 안전한 것으로 간주됩니다.

또다른 중요한 옵션은 토큰 생명주기 설정입니다. Keycloak을 사용하면 개별 클라이언트의 접근 토큰 생명주기를 재정의할 수 있습니다. 또한 리프레시 토큰의 생명주기를 제어하는 클라이언트 세션 생명주기도 재정의할 수 있습니다. 해당 재정의를 통해 수명이 짧은 리프레시 토큰(1시간 미만)을 가진 수명이 긴 SSO 세션(하루 또는 1주)을 설정할 수 있습니다.

수명이 짧은 리프레시 토큰은 리프레시 토큰이 유출된 경우 영향을 줄일 수 있으며 애플리케이션 HTTP 세션의 생명주기를 단축할 수 있습니다.