Java EE 보안 - 응용 프로그램 클라이언트

Question

3 ~ 6 개의 다른 클라이언트가있는 Java EE 프로젝트를 작성 중입니다. 이 프로젝트는 오픈 소스이며 어떤 보안 메커니즘을 사용해야하는지/사용해야하는지 궁금합니다. 문제는 : 오픈 소스이기 때문에, 사용자가있는 누구나 자신의 클라이언트를 작성할 수 있다고 생각합니다 (사실은 아니지만 진정으로 가능할 수 있습니다). 그리고 서버/데이터베이스와 접촉합니다. 나는 다른 역할로 데이터베이스에 다른 데이터를 읽고 쓰는 모든 시나리오를 시도해 보았으며, 나는 그보다 더 높은 수준의 보안 메커니즘을 가지고 있다고 결론 지었다 (은 확인하기에 충분하지 않다.) 해당 계정 유형이 해당 ID로 해당 엔티티를 지속하도록 허용 된 경우 ...). 어떤면에서는 나는 클라이언트가 올바른 클라이언트라는 것을 알고 있어야합니다. 이 썼습니다. Jar 파일에 서명하면이 전체 문제를 해결할 수 있습니까? 아니면 다른 방법으로 해결할 수 있습니까?

-Yngve

Answer 1

그럼 소스는 누구나 사용할 수 있지만 배포 확실히 데이터베이스의 구성은 아니다. 응용 프로그램을 배포 할 때 역할이있는 사용자를 추가 할 수 있습니다. 가장 쉬운 방법은 데이터베이스에 유지하는 것입니다. 물론 테이블의 내용은 데이터베이스 관리자 만 액세스 할 수 있습니다. 데이터베이스 관리자는 필수 테이블에 액세스 할 수 있도록 응용 프로그램을 구성합니다. 사용자가 로그인을 시도하면 사용자 이름과 비밀번호를 제공해야합니다. 응용 프로그램은 사용자를 인증/권한 부여하기 위해 테이블을 읽습니다.

가장 일반적인 보안 유형입니다. 보안을 위해 보안 경로 (HTTPS)를 통해 자격 증명을 전달해야합니다. 보안 수준을 높이려면 HTTPS 클라이언트 인증을 사용할 수 있습니다. 모든 클라이언트에 대한 공개 키를 생성하고이를 서버의 개인 키로 서명함으로써이를 수행합니다. 그런 다음 클라이언트는 모든 요청마다이 서명 된 키를 보내야합니다.

EDIT : 사용자가 자신의 클라이언트를 작성할 수 있다고해서 응용 프로그램 보안이 떨어지지는 않습니다. 먼저 로그인해야하는 경우에도 애플리케이션에 액세스 할 수 없습니다. 로그인이 성공하면 세션 (쿠키)이 만들어지고 모든 요청과 함께 전달됩니다. Spring security을 살펴보십시오. 다소 익숙한 학습 곡선을 가지고 있지만, 한 번 수행하면 몇 분 안에 모든 애플리케이션에 보안을 추가 할 수 있습니다.

Answer 2

저는 실제로 서버 측에서 (역할에 따라) 사용 가능한 활동을 제한하는 것이 충분하지 않으면보다 큰 문제가 있다고 생각합니다. 사용자가 자신의 클라이언트를 작성하지 않더라도 원격 호출에 사용하는 메커니즘은 가로 채어 조작하기 쉽습니다. 결론은 서버에 대해 수행 할 수있는 가능한 호출을 제한해야하며 서버에 대한 각 호출을 잠재적 인 악의적으로 취급해야한다는 것입니다.

특정 인증 된 사용자가 클라이언트에서 클라이언트를 사용 중이지만 클라이언트를 사용하지 않는다면 괜찮을 수있는 서버 작업이 있다고 생각할 수 있습니까? 그렇다면 나는 당신이 당신의 고객에게 너무 강하게 의존하고 있다고 주장 할 것입니다.

그러나 비판하기보다는 질문에 대한 실제 답변도 제공하고 싶습니다. 악의있는 사용자를 상상하는 경우 jar 파일에 서명하는 것으로 충분하지 않다고 생각합니다. 일반적으로 공개 키 암호화는 소스를 리버스 엔지니어링하는 가상의 악의적 인 사용자가 공개 키에 액세스 할 수 있으므로 사용자가 구축 한 모든 인증을 스푸핑 할 수 있기 때문에 공개 키 암호화가별로 도움이되지 않을 수 있습니다.

궁극적으로 당신이 신뢰하는 시스템의 누군가, 그리고 당신은 그것이 누구인지 알아 내야하고 그들 주위에 당신의 보안을 기반으로해야합니다.예를 들어, 신뢰할 수없는 특정 회사의 사용자가 많을 수도 있고 관리자를 감독하는 관리자 한 명, 신뢰할 수있는 관리자가 있다고 상상해보십시오. 이 시나리오에서는 관리자가 시작할 때 특수 코드를 입력하고 해당 코드를 메모리에 저장하고 요청과 함께 전달하도록 클라이언트를 설정할 수 있습니다. 이렇게하면 사용자가 코드를 리버스 엔지니어링하면 관리자 코드가 생성되지 않습니다. 물론 클라이언트로부터 서버로의 호출은 가로 채기와 조작에 취약 할 수 있습니다 (이 요구 사항은 사용자의 목에 고질적 인 고통이 될 수 있습니다).

결론 : 사용자의 컴퓨터가 서버를 호출하는 경우 사용자가 서버를 호출하는 것보다. 사용자를 신뢰하지 마십시오. 그들이 사용하는 클라이언트가 무엇이든 관계없이 할 수있는 일을 제한하십시오.