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의 유효성 검사기와 위젯을 사용하여 메시지를 통해 사용자에게 안내하고 취약한 비밀번호 생성을 제한할 수 있습니다.

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

Qt Network 인증은 OAuth 2.0의 ID 계층인 OpenID Connect를 통해 JSON 웹 토큰(JWT)을 검색할 수 있습니다. 인증과 권한 부여는 종종 동일한 시스템의 일부입니다. 액세스 토큰, 새로 고침 토큰, ID 토큰은 민감한 데이터로 취급하세요. 플랫폼 보안 스토리지 또는 암호화를 사용하여 안전하게 보관하세요. 토큰을 일반 텍스트로 저장하지 마세요.

권한 부여 및 리소스 제공

권한 부여는 해당 리소스에 대한 사용자 권한 및 권한을 기반으로 사용자가 리소스에 액세스할 수 있는지 확인하는 것입니다. 적절한 권한이 없으면 사용자는 권한이 없는데도 리소스에 액세스하여 작업을 수행할 수 있습니다. 공격자는 데이터의 무결성을 수정 및 감소시키거나 리소스를 남용하여 서비스 거부를 일으킬 수 있습니다.

기본적인 예방 조치로 리소스 오용을 초래할 수 있는 작업을 실행하기 전에 권한 검사를 수행하세요. 이 확인은 사용자가 서버 측 리소스에 액세스할 때마다 수행할 수 있습니다. 사용자의 권한과 리소스에 대한 권한에 따라 사용자가 리소스에 대한 작업을 실행할 수 있는지 여부가 결정됩니다. 리소스에 따라 추가 권한 확인이 필요할 수도 있습니다. 사용자가 로그아웃하거나 애플리케이션에 더 이상 토큰이 필요하지 않은 경우 액세스 권한을 취소하고 토큰을 새로 고칩니다.

외부 사용자 에이전트 사용

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

RFC 8252에서는 권한 부여를 위해 임베디드 웹 뷰가 아닌 외부 사용자 에이전트를 사용할 것을 권장합니다. 애플리케이션이 임베디드 사용자 에이전트를 제어하고 애플리케이션과 권한 부여 노드 간의 권한 액세스를 분리하지 못합니다. 이 설정은 애플리케이션이 키 입력을 기록할 수 있고 잘못된 보안 감각으로 사용자를 속일 수 있으므로 안전하지 않습니다. 그러나 외부 사용자 에이전트가 실용적이지 않은 경우 Qt WebEngine 와 같이 적절하게 구성된 임베디드 브라우저를 사용할 수도 있습니다.

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

PKCE 및 상태 매개변수

PKCE(코드 교환을 위한 증명 키)는 인증 코드 흐름에서 인증 코드 가로채기 공격으로부터 보호합니다. Qt Network 권한 부여는 기본적으로 PKCE를 활성화합니다.

Qt Network 권한 부여는 기본적으로 임의의 상태 값을 생성하여 CSRF(사이트 간 요청 위조) 공격을 방지합니다. 상태 매개변수를 재정의하는 경우 하드코딩된 문자열을 사용하지 마세요.

플랫폼 고려 사항

리디렉션 URI 처리는 플랫폼에 따라 다릅니다. 모바일 플랫폼에서는 앱 클레임 URL을 통해 HTTPS 리디렉션 URI를 안전하게 처리할 수 있습니다. 데스크톱 플랫폼에서는 로컬호스트로의 HTTP 리디렉션 URI가 네이티브 애플리케이션에 유효한 옵션으로 남아 있습니다.

커넥티드 애플리케이션을 위한 보안 리소스

다음은 사이버 보안 지침을 위한 리소스입니다:

• 일반적인 취약점 열거 - 알려진 문제와 가능한 완화 기술의 카탈로그입니다.
• OWASP 치트 시트 시리즈 - 애플리케이션 보안을 위한 다양한 주제의 목록입니다.
• RFC 6749 - OAuth 2.0 인증 프레임워크
• RFC 8252 - 네이티브 앱을 위한 OAuth 2.0
• RFC 7636 - 코드 교환을 위한 증명 키(PKCE)