서블릿 보안(Security)

이렇게 웹 애플리케이션을 배포하고 나면 불특정 다수의 이용자들이 서버에 접속할 수 있게 됩니다. 이 때 보안은 상당히 중요한 요소입니다. 서블릿 스펙에서는 서블릿 보안을 4가지 개념으로 다룹니다. 인증(Authentication), 인가(Authorization), 비밀보장(Confidentiality), 데이터 무결성(Data Integrity) 가 그것입니다. 인증부터 한 번 알아보도록 하겠습니다.

인증은 접속한 클라이언트가 누군지 파악하는 것입니다. 아이디와 비밀번호를 입력하고 로그인을 하는 것이라고 생각하면 됩니다. 서버는 인증이 필요한 요청을 받으면 www-인증 헤더와 보안영역(realm)정보를 담은 응답을 보냅니다.

401코드를 받아본 브라우저, 보안 영역 정보에 기초하여 사용자 이름과 패스워드를 물어보게 됩니다. 로그인 하게 되면 다시 한번 더 HTTP 헤더에 사용자의 이름과 패스워드를 담아서 요청을 보냅니다. 그럼 서버에서는 사용자의 이름과 패스워드가 일치하는지를 체크한 다음 인가 작업을 하게 됩니다.

이 때 사용자의 아이디와 패스워드는 tomcat 루트 디렉토리 아래에 config 디렉토리에 있는 tomcat-users.xml 파일에 정의합니다.이 파일은 한 애플리케이션에서만 사용하는게 아니라 톰캣 서버 전체에 적용되는 내용이 기술되어 있습니다. 실제로 이 방법으로 사용자 인증을 하게 되면 파일 내용이 바뀔 때 마다 서버를 재시작 해야 한다는 문제점이 있습니다. 때문에 일반적인 회원 관리에는 사용이 어렵고 일반적으로 DB를 통해 이루어지게 됩니다.

인증을 받아야하는 페이지에 대한 정보는 배포 서술자에 기록하게 됩니다. 어떤 자원에 제약을 걸 것인지, 어떤 종류의 Http method일 때 제약을 걸 것인지, 어떤 역할을 가진 사용자들이 요청할 수 있는지 등을 정의할 수 있습니다.  즉, 인증과 인가 작업이 같이 묶여서 실행 된다는 것을 알 수가 있습니다. 그런데 위에 보면 BASIC 이라는 메서드를 정의하는 부분이 있습니다. 이는 인증 방식을 정의하는 것인데 컨테이너는 4가지의 인증 방식을 제공합니다.

이렇게 네 가지의 인증 방식이 있는데 FORM 방식을 제외한 나머지는 배포서술자에 <auth-method> 태그 아래에 method 부분만 수정하면 되는데 반해 FORM은 직접제작한 로그인 폼을 추가해 줘야 합니다.

이런식으로 배포서술자에 로그인폼의 위치를 정의해 줍니다. 하지만 form 방식은 보안에 매우 취약하기 때문에 데이터를보호하기 위한 수단이 필요합니다. 이때 사용하는 것이 HTTPS 입니다.

SSL은 대칭키와 공개키 암호화 방식을 사용하고 있습니다. 대칭키의 경우는 하나의 키로 암호화와 복호화를 가능하게 만든 것으로 문제점은 이 키가 유출되면 암호화의 의미가 없다는 것입니다. 공개키 방식은 공개키로 암호화 한 것은 비공개키로 복호화 할 수 있고 비공개키로 암호화 한 것을 공개키로 복호화할 수 있는 두 개의 키 쌍을 공개키와 암호키로 나누고 공개키는 클라이언트에게 배포합니다. 클라이언트는 공개키로 암호화를 해서 정보를 전송하고 이를 복호화 할 수 있는 비공개키를 가진 것은 서버 뿐이기 때문에 안전성이 보장됩니다. 서버는 비공개키로 암호화를해서 응답하는데 이렇게 되면 공개된 공개키로 복호화를 할 수 있기 때문에 안전성은 보장되지 않지만 비공개키를 가진 서버가 공개키 제공자라는 것을 보증해 주는 역할을 해 줍니다.

그러면 우리가 실제로 request 데이터의 보호가 필요할 때 어떻게 자원에 제약을 걸어둘 수 있는지 보겠습니다. 이때도 배포서술자를 사용합니다. <security-constaint> 항목 아래 <user-data-constraint> 항목에 데이터 기밀성과 무결성에 대한 것들을 선언해 줍니다.

배포서술자를 통해 나타낸 내용을 어노테이션을 이용해서도 표현할 수 있다.

실제로 클라이언트가 CONFIDENTAL 혹은 INTEGRAL 제약이 걸린 자원에 접근하는 경우를 살펴 보도록 하겠습니다. 만약 제약이 걸린 자원에 대한 요청이 http 요청으로 들어온다면 컨테이너는 https 요청으로 다시 요청할 것을 리다이렉트 시킵니다. 그러면 브라우저는 https 요청으로 다시 재요청하게되고 그때 컨테이너는 인증을 요청하게 됩니다.