Qt Network 인증 보안 고려 사항

이 페이지에서는 Qt Network 인증을 사용하는 애플리케이션에 대한 보안 고려 사항을 다룹니다. 여기 수록된 내용의 상당 부분은 OAuth 2.0 인증 프레임워크와 OpenID에 중점을 둡니다.

OAuth 2.0 프로토콜 흐름에 대해서는 RFC 6749를, 네이티브 애플리케이션과 관련된 보안 문제에 대해서는 RFC 8252를 참조하십시오.

액세스 제어

액세스 제어는 신원 및 권한을 확인하는 시스템을 사용하여 사용자에게 리소스를 프로비저닝하는 과정을 포함합니다. 따라서 액세스 제어에는 승인, 인증 및 로깅 서비스가 포함됩니다. Qt Network 인증의 API는 OAuth 2.0 인증 프레임워크에 중점을 두고 액세스 제어를 구현합니다. Qt Network 인증은 승인 코드 흐름(PKCE 포함)과 기기 인증 흐름을 지원합니다.

시스템의 경우, 권한과 허가에 따른 신중한 구분이 접근 제어의 첫 번째 단계입니다. 사용자 범주는 특정 리소스와 서비스에 접근할 수 있는 그룹을 결정할 수 있습니다. 마찬가지로, 리소스나 서비스에 대한 권한은 해당 리소스나 서비스에서 수행할 수 있는 작업을 결정할 수 있습니다. 애플리케이션에 필요한 OAuth 범위만 요청하십시오. 범위를 제한하면 토큰이 유출되었을 때의 잠재적 영향을 줄일 수 있습니다.

또한 시스템은 유연성과 감독을 위해 접근 관리를 구현해야 합니다. 보안에 지장을 주지 않으면서 사용자와 리소스를 쉽게 추가하거나 제거할 수 있도록, 접근 및 서비스 프로비저닝은 시스템 설계의 일부가 되어야 합니다. 활동 로그는 감사 및 보안 분석에 도움이 됩니다.

잘 알려진 설계 방식으로는 역할 기반 접근 제어 (RBAC)가 있습니다.

인증 및 싱글 사인온

인증은 사용자의 신원을 확인하는 과정입니다. 취약한 인증 방법은 잘못된 사용자에게 접근 권한을 부여하게 되어, 개인 데이터 유출 및 악의적인 행위 실행으로 이어질 수 있습니다.

연동된 애플리케이션은 제한된 리소스를 사용하는 사용자의 신원을 확인해야 합니다. 일반적으로 애플리케이션은 기존 데이터베이스에서 사용자 이름 및 비밀번호와 같은 사용자 자격 증명을 확인하여 사용자를 검증합니다. 이 방법은 허위 인증 및 데이터 유출에 취약합니다. 많은 완화 기법은 사용자 행동에 초점을 맞추며, 애플리케이션은 강력한 비밀번호 사용을 의무화하는 등의 보안 정책을 시행할 수 있습니다. 애플리케이션은 Qt의 유효성 검사기(validator)와 Widgets를 사용하여 메시지를 통해 사용자에게 안내하고, 취약한 비밀번호 생성을 제한할 수 있습니다.

싱글 사인온(SSO)과 같은 중앙 집중식 인증 시스템을 사용하면 비밀번호 및 신원 관리의 실수를 최소화할 수 있습니다.

Qt Network 승인(Authorization)은 OAuth 2.0 위에 구축된 신원 계층인 OpenID Connect를 통해 JSON 웹 토큰(JWT)을 가져올 수 있습니다. 대개 인증과 승인은 동일한 시스템의 일부입니다. 액세스 토큰, 리프레시 토큰, ID 토큰을 민감한 데이터로 취급하십시오. 플랫폼의 보안 저장소나 암호화를 사용하여 이를 안전하게 저장하십시오. 토큰을 일반 텍스트로 저장하지 마십시오.

권한 부여 및 리소스 프로비저닝

권한 부여는 사용자의 권한 및 해당 리소스에 대한 접근 권한을 바탕으로 사용자가 리소스에 접근할 수 있는지 확인하는 과정입니다. 적절한 권한 부여가 이루어지지 않으면, 사용자는 권한이 없음에도 불구하고 리소스에 접근하여 작업을 수행할 수 있습니다. 공격자는 데이터를 변조하여 무결성을 훼손하거나 리소스를 악용하여 서비스 거부(DoS)를 유발할 수 있습니다.

기본적인 예방 조치로, 리소스 오용으로 이어질 수 있는 작업을 실행하기 전에 권한 확인을 수행하십시오. 이 확인은 사용자가 서버 측 리소스에 접근할 때마다 이루어질 수 있습니다. 사용자의 권한과 해당 리소스에 대한 접근 권한에 따라 사용자가 리소스에 대해 작업을 수행할 수 있는지 여부가 결정됩니다. 리소스에 따라 추가적인 권한 확인이 필요할 수 있습니다. 사용자가 로그아웃하거나 애플리케이션에서 더 이상 필요하지 않을 경우, 액세스 토큰과 리프레시 토큰을 취소하십시오.

외부 사용자 에이전트 사용

RFC 8252에 따르면, 애플리케이션은 OAuth 2.0에 정의된 대로 인증 엔드포인트에 대해 외부 사용자 에이전트 또는 내장 사용자 에이전트 중 하나를 사용할 수 있습니다. 내장 사용자 에이전트는 일반적으로 애플리케이션 내에서 제공되고 제어되는 웹뷰입니다. 외부 사용자 에이전트는 요청 애플리케이션이 제어하지 않는 시스템 브라우저나 기타 애플리케이션을 말합니다.

RFC 8252는 인증 시 내장형 웹뷰보다는 외부 사용자 에이전트를 사용할 것을 권장합니다. 애플리케이션이 내장형 사용자 에이전트를 제어하기 때문에 애플리케이션과 인증 노드 간의 특권 액세스 구분이 제대로 이루어지지 않습니다. 이 구성은 애플리케이션이 키 입력을 기록할 수 있고 사용자에게 허위의 보안감을 심어줄 수 있으므로 안전하지 않습니다. 그러나 외부 사용자 에이전트를 사용하는 것이 현실적으로 어려운 경우에는 Qt WebEngine 와 같이 적절히 구성된 내장형 브라우저를 사용할 수도 있습니다.

또한 시스템 브라우저를 외부 사용자 에이전트로 사용할 경우, 브라우저 탭과 저장된 인증 정보를 통해 사용자 경험을 간소화할 수 있습니다. 예를 들어, 사용자는 브라우저에 저장된 사용자 이름과 비밀번호를 사용할 수 있습니다. 마찬가지로, 비밀번호 관리자를 외부 사용자 에이전트로 사용하면 편의성과 신뢰도가 높아집니다.

PKCE 및 상태 매개변수

PKCE(Proof Key for Code Exchange)는 인증 코드 흐름에서 인증 코드 가로채기 공격을 방지합니다. Qt Network 인증은 기본적으로 PKCE를 활성화합니다.

Qt Network Authorization은 크로스사이트 요청 위조(CSRF) 공격을 방지하기 위해 기본적으로 임의의 상태 값을 생성합니다. 상태 매개변수를 재정의하는 경우, 하드코딩된 문자열을 사용하지 마십시오.

플랫폼 관련 고려 사항

리디렉션 URI 처리는 플랫폼에 따라 다릅니다. 모바일 플랫폼에서는 앱이 주장하는 URL을 통해 HTTPS 리디렉션 URI를 안전하게 처리할 수 있습니다. 데스크톱 플랫폼에서는 로컬호스트(localhost)로 향하는 HTTP 리디렉션 URI가 네이티브 애플리케이션에 대해 여전히 유효한 옵션입니다.

연동 애플리케이션을 위한 보안 리소스

다음은 사이버 보안 지침에 대한 자료입니다:

• Common Weakness Enumeration (CWE) - 알려진 문제 및 가능한 완화 기법을 정리한 목록입니다.
• OWASP 치트 시트 시리즈 - 애플리케이션 보안을 위한 다양한 주제를 정리한 목록입니다.
• RFC 6749 - OAuth 2.0 인증 프레임워크
• RFC 8252 - 네이티브 앱을 위한 OAuth 2.0
• RFC 7636 - 코드 교환용 증명 키(PKCE)