| [ WWW ] in KIDS 글 쓴 이(By): seasons (오히려전법) 날 짜 (Date): 1996년09월02일(월) 11시13분35초 KDT 제 목(Title): WWW 강좌 10 : Java 배우기 (27) A.Fun.A.Day(403) WWW 강좌 10 : Java 배우기 (27) ----------------------------------------------- < 자바 백서 > 계속 4.2 자바환경에서 보안성(Security in Java Environment) 보안은 소프트웨어와 멀티미디어에서 "전자화폐(Digital Cash)"에 이르는 제작물과 서비스를 위한 인터넷 사용의 증가에서 높은 사례를요구한다. 여기서 다루는 보안의 영역은 어떻게 자바컴파일러와 실행시스템이 파괴된 코드(Subversive Code)를 생성하는 데서 응용프로그램 프로그래머를 제한 할 것인가 이다. 자바언어 컴파일러와 실행시스템은 잠재적인 잘못된 코드를 방어하는 여러 단계의 계층으로 구현되었다. 자바컴파일러 방어의 첫 번째 선중의 하나는 메모리할당과 참조모델이다. 간단하게 말해, 자바는 전통적인 C와 C++같은 다른 메모리를 가리키는 주소를 가지는 메모리인 "포인터"가 없다. 메모리 윤곽의 결정은 C와 C++처럼 컴파일러가 하지 않는다. 메모리 윤곽 은 실행시 결정되며, 그리고 자바언어 시스템이 실행되는 하드웨어/소프트 웨어의 플랫폼의 특성에 의존하여 잠재적으로 결정될 것이다. 자바인터프 리터는 실행시 실제 메모리 주소를 해결하는 상징적인 "Handle"을 통해 메 모리를 참조한다. 메모리 할당과 참조 모델은 프로그래머에게 완전히 불투 명하고, 완전히 실행시스템에 좌우되기 때문에, 자바프로그래머는 메모리를 가리키는 포인터를 위조할 수 없다. 메모리 구조를 뒤늦게 결합하는 것은 프로그래머가 클래쓰의 선언을 알고 있어도 물리적인 메모리 윤곽을 추측할 수 없다는 것이다. C와 C++의 메 모리 윤곽과 포인터 모델의 제거로, 자바언어는 뒷배경을 알아야 하고 포 인터를 메모리로 조작해야 하는 프로그래머의 능력을 제거했다. 궁극적으 로 더욱 신뢰할 수 있고 안전한 응용프로그램으로 이끌기 때문에, 이런 특 성은 프로그래머에게는 제한이기보다는 긍정적인 이익으로 보여야 한다. ⊙ 바이트코드 확인 과정 "적대적인 컴파일러(Hostile Compiler)"의 개념은 무엇인가 ? 자바 컴파일 러가 자바 원시 코드가 안전한 규칙을 벗어나지않을 것이라 확신한다고 해도, 어느 곳으로부터든 핫자바 브라우져와 같은 응용프로그램이 코드의 부분을 가져올 때, 완전한 자바언어의 규칙을 코드들이 따라준다고 생각해 서는 안된다 - 코드는 Known-to-be-trustworthy 자바컴파일러가 만들지 않았기 때문이다. 그런 경우에, 어떻게 당신의 컴퓨터의 자바실행시스템이 바이트코드들을 신뢰할 수 있는가 ? 답은 간단하다 - 수입된 코드는 신뢰 하지 않지만, 바이트코드 확인을 통해 지배된다. 테스트는 코드의 부분의 형식이 올바르다고 하는 간단한 확인에서 규칙에 의해 코들이 동작하는 것을 확인하는 간단한 정리의 증명까지 그 범위를 갖는다 - 포인터를 위조하지 않았는가, 접근 제한을 넘지 않았는가, 객체로 써 객체에 접근하지 않았는가 등을 검사한다(예로, "InputStream" 객체는 항상 "InputStream"으로만 쓰이지 다르게 쓰이지 않는다). 안전하고, 발생 된 코드를 실행시스템의 확인을 추가한 언어는 인터페이스가 위반할 수 없 다는 기본적인 보증을 확인한다. ⊙ 바이트코드 확인자(Byte Code Verifier) 바이트코드 로더의 마지막 단계는 확인이다. 그것은 바이트코드를 자세히 살피며, 종류의 상태에 대한 정보를 구성하고, 모든 바이트코드 명령에 대 한 매개변수의 종류를 검사한다. 위의 그림은 자바 원시코드에서 자바컴파일러를 통해 바이트코드 확인기와 자바인터프리터로 가는 데이터와 제어의 흐름을 보여준다. 자바클래스로더 와 바이트코드 확인기가 일차적인 바이트코드 흐름의 소스에 대해 어떤 가 정도 하지 않는 것은 대단히 중요하다 - 그 코드가 자신의 컴퓨터에 올 수 도 있고, 지구반대편에서도 올 수도 있다. 바이트코드 확인기는 문지기 (GateKeeper)로 활동한다. 바이트코드 확인기는 자바 인터프리터로 전해진 코드가 자바인터프리터를 깨뜨리는 위협 없이 실행되거나 동작할 수 있는 적당하다는 것을 확신한다. 수입된 코드는 검사기의 테스트를 지나기 전까 지는 어떻게든 동작할 수 없다. 검사가 끝나면, 다음과 같은 특성이 알려진 다. 1. 오버플러워나 언더플러워된 피연산자 스택은 없다. 2. 모든 바이트코드 명령의 타입은 항상 올바르게 알려진다. 3. 정수에서 포인터로 옮기는 것 같은 부적당한 데이터변환은 없다. 4. 객체 필드 접근은 적법한 것이다 - private orpublic or protected 이런 모든 검사가 대단히 자세한 것일 때, 시간이 다 될 때까지 바이트코 드 확인기는 자신의 일을 다 끝내고, 자바인터프리터가 코드가 안전하게 동작할 것이라는 것을 알고 동작 할 수 있다. 인터프리터가 아무것도 검사 하지 않아도 되기 때문에, 이런 특성을 아는 것은 자바인터프리터를 더욱 빠르게 동작시킬 것이다. 피연산자 종류 검사나, 스택오버플러워 검사도 없 다. 인터프리터는 신뢰성을 상실하지 않고 최대의 속도로 이런 일을 할 수 있다. ⊙ 클래스 로더에서 보안성 검사(Security Checks in the Class Loader) 수입된 코드를 검사하고(Vetted-동물을 진찰한다는 의미가 강함) 바이트코 드 확인기가 깨끗함을 결정한 후에, 방어의 다음 선은 자바 클래스 로더이 다. 자바 바이트코드가 동작되는 쓰레드의 실행이 보여준 환경은 부분화된 클래스들의 집합을 분리된 이름 공간(Separate Name Space)으로 가시화 한다. 자신의 파일시스템에서 가져온 클래스는 하나의 이름 공간이 있고, 각 네트워크를 위한 분리된 이름 공간이 있다. 클래스가 네트워크상에서 수입되면, 클래스의 발생지에 관계된 개별적인 이름 공간에 위치 되게 된다. 하나의 클래스가 다른 클래스를 참조한다면, 현재의 컴퓨터시스템(내장된 클래스)에서 이름 공간을 먼저 찾아보고, 다음 번에 참조하고 있는 클래스의 이름 공간에서 찾는다. 수입된 클래스가 내 장된 클래스라고 "위장"할 수 있는 방법은 없다. 내장된 클래스는 수입된 이름 공간에서 클래스를 참조하지 않는다 - 그들은 오직 명백하게 참조한 다. 유사하게, 다른 장소에서 수입된 클래스는 각각으로로부터 분리된다. ⊙ 자바 네트워킹 패키지에서 보안성 자바의 네트워킹 패키지는 FTP, HTTP, Telnet 등의 다양한 프로토콜을 다룰 수 있는 인터페이스를 제공한다. 이것이 바로 당신이 네트워크 인터 페이스 단계에서 최전방의 방어이다. 네트워킹 패키지는 편집증적인 한정 된 단계의 설치를 할 수 있다. 다음과 같은 것을 할 수 있다. 1. 전체 네트워크가 접근하지 못하게 한다 2. 전체 네트워크가 접근할 수 있게 한다 3. 코드가 수입되는 호스트만 네트워크 접근을 허락 4. 코드가 외부에서 들어온다면 오직 방화벽(FireWall)을 통해서만 접근을 허락 -- ___o ___o ___o ___o ___o __ \\ __ __ \\ __ __ \\ __ __ \\ __ __ \\ __ (*)/ (*) (*)/ (*) (*)/ (*) (*)/ (*) (*)/ (*) +---------------------------------------------------------------------------+ | Won Geun Baek E-Mail: wgbaek@pharaoh.telecom.samsung.co.kr | | Samsung Electronics co. http://pharaoh.telecom.samsung.co.kr/~wgbaek | | Karak-Dong, Seoul, Korea TEL : 02-405-1376 (7:00-18:00 Korea) | +---------------------------------------------------------------------------+ |