한빛출판네트워크

저자: 스콧 오크스, 역 이호재

보안을 고려하는 것은 자바 플랫폼의 디자인에 많은 영향을 미친다. 이러한 예로는 전자 서명을 위한 클래스를 포함한 보안 메니저와 J2SE(자바 2 표준 버전)가 있다. 또한 자바 2 1.3 버전에는 세 가지 중요한 보안 확장이 있다. 더군다나 보안은 자바의 클래스 로더의 디자인과 배열 경계 체크 등의 많은 언어 규칙과 java.lang.String 클래스와 같은 많은 클래스의 구현에 영향을 미친다.

자 어디서부터 시작해야 할까? 『Java Security, 2nd Edition』(『자바 시큐리티 프로그래밍』, 한빛미디어, 2001)에서는 자바 보안 구조의 개관부터 시작해서, 중요한 자바 보안 도구를 이용하는 방법과 로드하는 클래스의 추가적인 퍼미션을 위해 URL 클래스 로더를 사용하는 것, 그리고 P와 Q라는 특별한 매개변수(DSA 키를 계산하는데 사용되는 매개변수)를 통해 DSA 키를 생성하는 것까지 자바 보안과 관련된 모든 것을 다룬다. 이 기사에서는 여러분들이 어디서부터 시작해야 할지를 알려주는 가장 중요한 팁들을 간추려 놓았다. 그러면 지금부터 자바 보안 구조를 이용하기 위한 10가지 팁을 살펴보도록 하자.

		자바 시큐리티 프로그래밍

1. 모든 것은 보안 관리자와 함께 실행시켜라.

가장 잘 알려진 자바 보안 구조의 양상은 애플릿이 특정 옵션을 수행함에 있어 제한적이라는 점이다. 이 제한은 보안 관리자에 의해 강제로 통제된다.

그렇지만 보안 메니저는 단지 애플릿을 위한 것이 아니라는 점을 알아두어야 한다. RMI 서버와 같은 애플리케이션도 올바르게 작동되기 위해서는 보안 관리자를 설치해야 한다. 물론 모든 애플리케이션은 보안 관리자로부터 이득을 얻을 수 있다. Acme 소프트웨어로부터 자바 애플리케이션을 방금 다운받았다고 가정해보자. Acme는 믿을만한 소프트웨어 회사이기 때문에 그 소프트웨어에 바이러스를 심어놓지는 않았을 것이다. 하지만 우연하게 소프트웨어에 바이러스가 포함될 수는 있으며 심지어 아주 유명한 소프트웨어 회사도 자신들도 모르는 사이에 바이러스에 감염된 소프트웨어를 배포한 사실이 있다.

Acme에서 제작한 소프트웨어가 C++로 작성되었다면 발송하기 전에 소프트웨어가 바이러스에 감염되지 않았기를 바라는 것 이외에는 할 수 있는 게 별로 없다. 하지만 소프트웨어가 자바로 제작되었다면 이야기는 달라진다. 여러분은 그 소프트웨어를 보안 관리자의 보호 아래 실행 할 수 있기 때문이다. 따라서 소프트웨어가 중요한 시스템 파일이나 기타 다른 중요한 문서에 접근하거나 삭제할 수 없게 방지할 수 있다.

보안 관리자를 사용하는 것은 모든 자바 프로그램에 있어서 선택사항이다. 애플릿을 실행하는 컨테이너(애플릿뷰어나 자바 사용 가능한 브라우저 등)의 경우 자동으로 보안 관리자를 설치한다. 그렇지 않으면, 보안메니저를 설치하는 것은 여러분에게 달려있다. 만약 여러분이 애플리케이션을 만든다면 이것은 프로그램 절차에 따라 실행될 수도 있지만 자바를 시작할 때 -Djava.security.manager라는 플래그를 포함하여 명령 라인에서 보안 관리자의 사용을 명세해 주는 것이 훨씬 더 쉽다.

자바 초창기에는 자바 보안 모델의 "심각한 결점"(명령행에서 실행하는 애플리케이션이 파일을 읽을 수 있거나 네트워크 연결을 할 수 있다는 점 등등)에 대해 사람들이 말하는 것을 종종 들을 수 있었다. 그렇지만 지금은 대부분의 사람들이 이러한 관점에서 애플리케이션과 애플릿의 차이는 구분해 낸다. 그리고 그들 중 아주 소수만이 보안 관리자와 함께 애플리케이션을 실행해야 함을 깨닫고 다음 단계로 더 발전해 나간다

2. 인증서의 사용을 고려하라.

자바 보안 인프라의 특징 중 대다수가 디지털 인증서(정확히는 X509 인증서)에 기초하고 있다. 여러분은 .jar 파일 안에 들어있는 코드에 더 많은 퍼미션을 주기 위해 .jar 파일에 디지털 인증서로 서명을 한다. 또한 SSL(Secure Socket Layer)을 사용하는 서버를 설치하기 위해 디지털 인증서를 사용하며, 암호화를 위해 디지털 인증서를 사용할 수도 있다.

100% 완벽한 세상에서는 우리 모두가 디지털 인증서를 가지고 있기 때문에 그것을 아주 간단하게 사용할 수 있다. 하지만 실제 세계는 100% 완벽이라는 말과는 거리가 멀다. 디지털 인증서는 다루기가 어려우며, 자바에 들어있는 도구들은 기업은 말할 것도 없고 워크그룹을 위한 디지털 인증서 집합을 다루기에도 적합하지 않다. 설상가상으로 자바 애플리케이션과 다른 애플리케이션 간의 디지털 인증서를 공유하는 것은 어렵다.

하지만 다행스럽게도 디지털 인증서를 위한 인프라가 최근 몇 년 동안 급격히 발전했다. 사실 디지탈 인증서를 얻는 일이 이보다 더 쉬운 때는 없었던 것 같다. 단순히 Thawte 웹사이트를 방문한 다음 "개인 인증서"를 클릭하면 되기 때문이다. 일단 웹사이트의 개인 인증서 프로그램에 등록했다면 여러분은 모든 자바 애플리케이션에서 사용할 수 있는 여러분만의 인증서를 갖게 된 것이다. 이것은 무료일 뿐만 아니라 획득하기도 쉽다.

하지만 자바의 가장 중요한 보안 기능을 이용하기 위해 반드시 인증서가 필요한 것은 아니라는 점을 기억하고 있는 것이 좋다. 특히 추가적인 퍼미션을 갖기 위해서 코드를 서명할 필요는 없다는 뜻이다. 자바가 작업을 수행하는 퍼미션은 코드가 로드되는 위치와 코드를 서명한 사람의 조합에 기초하여 결정된다. 이 조합의 두 부분은 모두 선택적이다. 만약 oreilly.com에 있는 코드가 시스템에 있는 파일들을 읽을 수 있는 퍼미션을 갖게 하려면, 단순히 java.policy 파일에 다음과 같은 항목만 만들면 된다.

grant codebase "http://www.oreilly.com/" {
    permission java.io.FilePermission "<>", "read";
};

만약 인터넷과 같이 네임 서버를 신뢰할 수 없는 네트워크상에 있다면 위와 같이 오직 URL에만 의존한 퍼미션은 실행하기에 위험한 일이다. 하지만 만약 안전한 네트워크상에 있거나 클래스를 파일 시스템으로부터 로딩하고 있다면 이것은 실행하기에도 안전하다고 말할 수 있다. 만약 당신이 작성한 자바 애플리케이션을 배포하려 한다면 사용자로 하여금 애플리케이션을 https 상에서 다운받게 하고 애플리케이션 .jar 파일을 로컬에 설치하게 하고 적절한 파일에 근거한 URLs 적절한 퍼미션을 부여하게 하는 것이 좋다.

3. 자바 플러그인과 RSA 인증서를 사용하라.

만약 인터넷상에서 애플리케이션을 실행하고 그것에 추가적인 퍼미션을 할당하기를 원한다면 애플리케이션을 포함하고 있는 .jar 파일에 서명을 하고 사용자에게 서명한 .jar 파일에게 추가적인 퍼미션을 허용하도록 요구하는 방법밖에 없다.

극소수의 브라우저만이 자바 2 보안 모델을 지원한다(넷스케이프 6과 오페라 브라우저만이 자바 2 보안 모델을 지원함). 인터넷 익스플로러나 이전 버전의 넷스케이프를 포함한 다른 브라우저들은 자바 플러그인을 통해서만 자바 2 보안 모델을 지원할 수 있다. 즉 이러한 브라우저에 내장된 자바 가상 머신은 자바 2 보안 모델을 지원하지 않는다(자바 2의 고분고분한 요구에도 불구하고).

이 경우 여러분이 할 수 있는 최선의 방법은 자바 플러그인을 사용하는 것이다(넷스케이프 6 및 오페라는 자동적으로 자바 플러그인을 사용하도록 되어있음). 그리고 자바 플러그인을 사용함으로써 얻을 수 있는 추가적인 이익이 있다. 대개 사용자들은 policytool을 실행하거나 특정 지역에서 로딩된 코드를 위해 명시적으로 퍼미션을 나열하거나 특정 조직에 의해 서명된 하나 또는 그 이상의 java.policy 파일을 편집함으로써 퍼미션을 부여한다. 하지만 만약 애플릿을 RSA 인증서를 통해 서명하고 자바 플러그인 1.3 버전 이상을 통해 실행한다면 사용자는 정책 파일을 수정할 필요가지는 없다(물론 정책 파일이 무엇인지 알고 있을지라도 수정할 필요가 없다). 자바 플러그인이 RSA 인증서에 의해 서명된 애플릿을 만나면 자바 플러그인은 그 애플릿이 보안 관리자가 애플릿에게 부여하는 모든 제약들을 무시해도 되는지를 물어보게 된다. 사용자는 그 애플릿이 현재 세션에 있는 모든 제약을 풀어주도록 허용할 수 있다. 현재 세션뿐만 아니라 항상 그러한 권한을 줄 수도 있고, 아예 안 줄 수도 있다.

특별한 정책 파일도 없을 뿐만 아니라 특별한 퍼미션도 필요 없다. 사용자가 조작할 수 있는 간단한 대화상자만이 필요할 뿐이다.

4. 보안 확장 모듈을 설치하라

자바 보안 구조를 위한 3가지 중요한 확장 모듈이 있다. 첫번째로 JCE(Java Cryptography Extension)는 다양한 알고리즘을 사용하는 강력한 암호화 모듈로 이를 이용해 코드를 개발할 수 있게 해준다(추가로 보안키 교환 같은 작업도 가능). 두 번째로 JSSE(Java Secure Sockets Extension)은 SSL 자바 인터페이스를 제공한다. 마지막으로 JAAS(Java Authentication and Authorization Service)는 프로그램을 실행시키는 엔드유저의 신분을 확인하고, 특정 엔드유저만이 특정 작업을 수행하도록 인증한다.

현재는 자바 2 플랫폼 1.3 버전을 위한 확장 모듈이 있다. 즉 이 모듈들을 각각 다운받아야 하며 번들되거나 번들되지 않은 확장 모듈로 사용해야 함을 의미한다. 이것들은 번들된 확장 모듈로 사용하는 것이 훨씬 쉽다. 이 경우 .jar 파일을 $JAVAHOME/lib/ext에 설치하면 세팅이 끝난 것이기 때문이다. 그러나 번들되지 않은 확장 모듈의 경우 애플리케이션을 위해 .jar 파일을 classpath에 포함시켜야 하는 수고를 더 들여야만 한다.

위에서 언급한 확장 모듈을 어떻게 설치하든 간에 이러한 확장 모듈에 대해 알아둘 필요는 있다. 개발자들에게 있어 확장 모듈은 자바와 함께 아주 유용한 보안 API를 제공한다. 핵심 플랫폼 API는 메시지 개요나 전자 서명을 만들 수 있기는 하지만 개발자들은 데이터를 암호화하고 사용자를 인증하는데 더 많은 흥미를 보이고 있다.

이 확장 모듈들은 자바 1.4의 핵심 릴리즈에 포함될 예정이다. 바로 이런 이유로 인해 이 확장 모듈은 번들된 확장 모듈로 취급되고 있으며 자바 1.4로 업그레이드 될 때 사용하게 될 방법으로 자리잡을 것이다.

현재 JCE와 JSSE는 확장 모듈로서 사용 가능하다. 그리고 모듈은 더 이상 미정부 수출 금지 품목에 포함되어 있지 않다. 이전 버전의 확장 모듈들은 미국과 캐나다 내에서만 사용될 수 있었으며 이것은 이 확장 모듈을 사용하는 프로그램들도 인터넷에서 사용할 수 없음을 의미했다. 미정부의 정책 변화로 썬 마이크로시스템즈는 이 확장 모듈을 전 세계로 배포할 수 있게 됐다. 물론 일부 나라는 이 패키지 수입을 여전히 제한하고 있기 때문에 몇몇 나라에서는 이 모듈을 사용할 수 없다. 더 자세한 사항을 알고 싶다면 Java Secure Socket Extension(JSSE) 1.0.2를 보기 바란다.

5. SSL 서버 이름을 검증하라.

JSSE는 SSL을 사용하기 위해 API를 제공한다. SSL은 소켓 프로토콜이기 때문에 API는 자바의 표준 소켓 의미 규칙을 따르는 클래스를 제공한다. 예를 들어 SSLSocket 클래스는 Socket 클래스를 상속받으며, SSLServerSocket 클래스는 ServerSocket 클래스를 상속받는다. 이는 그냥 소켓과 SSL 소켓이 상호 변환 할 수 있게 해준다. 사실상 JSSE는 이러한 추상화를 위해 소켓 생성기를 제공한다.

하지만 이 모든 것에는 다음과 같은 한 가지 복잡한 사항이 있다. SSL 소켓과 보통 소켓은 호스트와 포트의 연결을 통해 생성되는데 이는 소켓 생성기가 제공하는 인터페이스이다. 하지만, 극도의 안전을 위해서라면 SSL 소켓은 추가적인 초기화 작업이 반드시 필요하다.

SSL 클라이언트가 SSL 서버에 접속할 때 내부적으로는 많은 일들이 일어난다. 서버는 클라이언트에게 자신의 인증서를 전송하고, 클라이언트는 인증서를 검증하는데, 이때 클라이언트와 서버는 사용할 암호화 알고리즘 등을 결정한다. SSLSocket 객체가 생성되면 이와 같은 모든 초기화 작업은 끝나게 된다. 그러나 이때 클라이언트는 서버가 제공한 인증서의 유효성을 검증하였지만 서버의 신원을 확인하지는 못했다. 이 시점에서 모든 클라이언트들은 서버가 클라이언트가 신뢰하는 인증서 발급 기간에서 발급된 유효한 인증서를 소유하고 있다는 것을 알고 있다.

애플리케이션이 올바른 서버에 접속되어 있는 것을 보증하고 더 발전된 단계로 나아가는 것은 애플리케이션 개발자들이 책임져야 할 의무이다. 이 작업은 보통 인증서 내에 포함되어 있는 이름을 검색함으로써 수행된다. 인증서의 이름은 인증서를 소유하고 있는 사이트의 이름과 일치해야 한다. 그래서 만약 www.sun.com의 SSL server에 접속한다면 인증서 내의 이름이 여러분을 www.sun.com으로 전송시켜 줄 것이다. 따라서 애플리케이션 개발자는 인증서 내에 있는 이름을 검색하는 코드를 제공해야 하며 애플리케이션이 접속하고자 하는 호스트의 이름과 인증서의 이름이 일치하는지도 검사해야 한다.

종종 여러 가지 사정으로 이름이 일치하지 않을 때도 있다. 애플리케이션이 호스트 이름을 사용하지 않고 IP 주소를 지정했을 때 또는 어떤 사이트가 잘못된 이름으로 된 인증서를 갖고 있을 때 등이 이런 경우의 적절한 예가 될 것이다. 따라서 인증은 철저해야 한다. IP 주소를 받아서 다른 것들과 비교해 보아야 하며 만약 서로 뜻이 통한다면 애플리케이션은 사용자에게 이름이 서로 맞지 않을 경우 인증서를 수락할 것인지 아닌지를 물어볼 수 있다.

그러므로 인증을 어떻게 다룰 것인지는 애플리케이션에 종속적일 수 밖에 없다. 그러나 소켓 API의 프로토콜 독립적인 특징들로 인해 여러분이 이와 같은 중요한 단계를 수행하지 못하게 하지는 말아라.

6. 여러분의 기업환경에 맞는 구현을 계획하라.

자바의 핵심 보안 구현은 단일 플랫폼 상의 단일 유저에게는 안정맞춤이다. 그렇지만 다른 해결책을 원할 경우 어떻게 해야 할까? 인증서는 keytool이 관리하는 파일 안에 있다. 이 파일은 로컬 워크그룹 내에 공유할 수 있다. 그러나 도쿄와 오사카처럼 서로 멀리 떨어진 사무실에서 공유하고자 한다면 어떻게 해야 할까? 다양한 java.policy 파일의 항목에 있는 엔트리에 근거하여 코드에 퍼미션이 부여되는데 이것을 집중된 한 장소에 저장하고자 한다면 어떻게 해야 할까? JAAS는 JAAS를 인증한 사용자에게 퍼미션을 주도록 설치되어 있다. 하지만 이러한 퍼미션이 사용자의 이름과 같은 임시변통적인 원칙에 따라 정의되길 원한다면 어떻게 해야 할까?

여기서 언급한 것 이외에도 더 많을 수도 있지만 이러한 모든 일들은 고유의 몇몇 키 및 자바 클래스(핵심 자바 클래스) 구현을 제공함으로서 이룰 수 있다. 자바의 보안 구조는 기본값이 설정되는 방식으로 정의되는데 이러한 클래스의 포컬 사용자 기반의 구현은 여러분이 처한 환경에 적합하게 조정된 구현에 의해 쉽게 대체될 수 있을 수 있다. 각 클래스에 부여되는 퍼미션을 결정하는 Policy 클래스의 기본값 구현을 바꾸는 것이 극단적인 일처럼 보일 수 있지만 사실은 그렇지 않다. 이는 많은 환경에서 매우 당연한 일이며 보안 API에 의해 정의된 기본 작동이기 때문이다.

자바의 기본 보안 클래스를 이러한 방법으로 확장 가능하게 하는 서드 파티 패키지들이 점점 늘고 있다. 더 다양한 솔루션이 필요하다면 솔루션 시장을 검사해보길 바란다.

7. 올바른 암호화 매개변수를 사용하라.

JCE는 DES, DESede(또는 triple DES), Blowfish 등 다양한 알고리즘을 사용해서 암호화를 수행하는 API를 제공한다. 알고리즘이 작동할 모드는 사용할 알고리즘을 선택하는 것만큼 중요한 것이다. 따라서 암호화하고자 하는 데이터 종류에 따라 모드를 선택해야 한다.

암호화의 기본 모드는 ECB(Electronic CookBook)이다. 이 모드는 한번에 데이터를 한 블록(8바이트)씩 암호화 한다. 암호화된 텍스트가 재정렬 된다 하더라도 암호화된 텍스트는 여전히 성공적으로 해독될 수 있을 것이다(물론 결과물로 나온 암호화 이전의 텍스트는 그 순서가 바뀌게 되겠지만…). ECB 모드는 패턴을 검색함으로서 성공적으로 공격 당할 수 있다. 이러한 이유로 텍스트 데이터를 암호화하는 것은 적절하지 못하다. 즉, 이는 바이너리 데이터를 위해서만 사용되어야 한다.

어떤 종류의 텍스트는 CBC(Cipher Block Chaining) 모드를 사용해 암호화는 것이 적당하다. email 헤더에서처럼 이 모드는 텍스트의 첫 부분에 패턴이 발생하지 않는 한 텍스트 데이터 내의 패턴을 숨길 수 있다. 이 모드는 키 교환 기술에 사용되는 PBEwithMD5AndDes 등과 같이 특별한 알고리즘을 위해 가장 잘 사용된다.

텍스트는 OFB(output FeedBack) 모드나 CFB(Cipher Feedback) 모드를 사용해 더 잘 암호화 된다. 이 모드는 텍스트의 모든 패턴을 숨길 수 있다. OFB는 모뎀과 같이 전송 중 노이즈가 발생할 수 있는 라인에서 사용하기 위해 고안되었다. 다른 모드로 암호화된 데이터에서 한 비트의 데이터가 바뀌면, 8바이트짜리 블록 전체를 잃어버리게 되며 OFB모드에서는 오직 1비트만을 잃어버리게 된다. 만약 자동적으로 데이터를 해독, 암호화하는 입출력 스트림을 사용하고자 한다면 숫자 8로 확장된 모드 중 하나를 사용해야 한다(예: CFB8). 이는 데이터가 8비트짜리 블록으로 처리되기 때문이다. 그렇지 않으면 스트림은 데이터를 처리하기 전에 64비트 데이터를 버퍼링 할 것이다.

8. 외부 환경을 이해하라.

필자는 최근에 필자와 필자의 친구가 일 때문에 종종 접근하는 웹사이트의 사용을 자동화하는 프로그램을 만들었다. 이 웹사이트는 사용자 이름과 패스워드를 요구하고, 사용자가 데이터를 다 입력하고 나면 다시 문서로 되돌아 가게 되어있다. 즉 자동화 프로그램을 이용하여 문서를 불러오는 스크립트를 간단히 실행만 하면 된다.

우리는 패스워드를 어떻게 다룰까에 대해서 고민하였다. 스크립트가 임의의 시간에 자동으로 실행할 수 있기를 원했기 때문에 실행할 때마다 패스워드를 입력할 수 없었기 때문이다. 그리고 내 동료 중 몇몇은 스크립트에 보호 받지 못하는 패스워드를 남겨 놓는 것에 대해 걱정스럽게 생각했다. 따라서 패스워드가 스크립트 내에 저장되기 위해서는 암호화할 필요성이 있다.

내가 행한 정정 작업은 물론 JCE의 강력한 암호화 API를 사용한 것이다. 이상적으로 그것은 모든 사람의 개인 인증서에 기초하여 작업할 수 있지만 그렇게까지 하지는 않았다. 필자는 필자의 동료도 몇 시간 내에 알아낼 수 있는 취약한 암호를 구현하였다(그는 한 번에 그 사실을 발견하였음).

필자는 필자가 꽤 게으른 프로그래머라는 것과 가장 간편한 방법을 찾아 구현한 암호화였음을 시인한다. 하지만 다른 관점(우리가 접속하는 웹사이트가 https를 사용하지 않는다는 점)에서 보면 이치에 맞다. 따라서 필자의 패스워드에 관심이 있는 사람은 필자의 스크립트를 찾아내 암호화 기술을 깨뜨림으로써 패스워드를 훔칠 수 있을 것이다. 그러나 굳이 그렇게 복잡한 방법 대신 암호화 되지 않은 패스워드가 웹 서버로 전달 될 때 필자의 네트워크를 스누핑함으로써 훨씬 간단하게 패스워드를 얻을 수 있다.

보안은 자바를 둘러싼 것들 중에 있어 애매모호한 것 중의 하나이고 결과적으로 자바에서 보안에 관련된 것들은 다른 환경적 요인들보다 훨씬 더 정밀한 주제에 속한다. 그러나 자바가 얼마나 안전한지 또는 자바 애플리케이션에 어떤 보안 요소들을 추가할 수 있는지는 중요하지 않다. 나머지 환경이 안전하지 않을 경우 이러한 자바의 장점들은 별로 도움이 되지 않기 때문이다.

(그렇다고 해서 이것을 변명하는데 사용하지는 말아라. 언젠가 필자와 필자의 친구가 사용하는 웹사이트가 이러한 방법의 어리석음을 깨닫고 https를 사용하기 시작할 수 있다. 이때는 필자의 프로그램을 수정할 수 밖에 없을 것이다. 시작할 때부터 올바르게 하는 것이 더 좋은 방법이다.)

9. 사용자를 그들 자신으로부터 보호하라.

자바의 보안 구조는 6번 팁에서 언급했듯이 아주 유연하다. 이는 그들 자신이 무엇을 하는지를 이해하는 사람들에게 있어서는 안성맞춤 이기는 하지만 때때로 사용자들이 그들 자신들로부터 보호 받길 원하는 환경에 있을 수 있다. 참고로 내가 그러한 오만한 시스템 관리자라는 것은 아니다.

사용자들이 빠지기 쉬운 가장 큰 위험은 신뢰할 수 없는 코드가 허용되어서는 안되는 작업을 수행하게 하는 엔트리가 정책 파일에 있는 것이다. 기본값으로 각 사용자는 그러한 퍼미션을 부여하는 $HOME/.java.policy 파일을 가지고 있다. 또한 이러한 퍼미션은 사용자가 -Djava.policy 인자를 명령 라인에서 지정하는 것 뿐만 아니라 $JAVAHOME/lib/security/java.policy 파일에 나열되어 있는 것에 추가할 수도 있다.

여러분은 $JAVAHOME/lib/security/java.security 파일을 아래와 같이 수정함으로써 보안 구조의 이러한 성질을 해제할 수 있다.

   아래와 같이 쓰여 있는 라인을 삭제하라.
   policy.url.2=file:${user.home}/.java.policy

   아래와 같이 쓰여있는 것을 주석 처리하라.
   policy.allowSystemProperty=true

이와 같이 수정한 후, 자바 애플리케이션을 실행할 때 오직 $JAVAHOME/lib/security/java.policy에 나열되어 있는 퍼미션만이 유효할 것이다. 사용자는 어떠한 자바 클래스에 추가적인 퍼미션을 부여할 수 없을 것이다.

물론 이것을 완벽하게 효과적으로 사용하기 위해서는 최종 사용자가 $JAVAHOME/lib/security 디렉토리에 있는 파일을 수정할 수 없게 해야 한다.

10. 최근의 일에 귀를 기울여라.

만약 당신이 정말로 자바의 보안에 대해 지대한 관심을 갖고 있다면 자바 세계에서 일어나는 최근의 일에 귀를 기울여야 한다. 특히 java.snu.com를 방문해보면 자바 보안 구조와 관련된 모든 사이트들과 링크가 잘 되어있다. 자바 보안 모델의 구현에 있어서 버그가 발견된다면 물론 버그 관련사항도 이 사이트에 포스팅이 된다.

스콧 오크스는 1987년부터 썬 마이크로시스템즈에서 근무한 자바 기술자이다. 그곳에서 기술자로 근무하면서 그는 SunOS 커널에서 네트워크 프로그래밍과 RPC 등에 이르는 일관적인 기술들을 전문적으로 개발하였다. 1995년 이후로 자바관련 사업을 주로하고 있으며 자바 기술을 엔드유저에게 소개하고 있다.