2.2. 보안 원리

잘 알고 있어야 하는 많은 일반적인 보안 원리들이 있다; 정보 보안에 대한 일반적인 정보를 얻을 수 있는 한 곳은 Information Assurance Technical Framework (IATF) [NSA 2000] 이다. NIST 는 높은 수준의 ``일반적으로 인정된 원리와 실제 (generally accepted principles and practices)" 을 식별하였다 [Swanson 1996]. [Pfleeger 1997] 같은 컴퓨터 보안에 대한 일반적인 교재도 또한 볼 수 있다. 약간의 보안 원리들은 다음과 같이 요약된다:

대개 컴퓨터 보안의 목적은 다음 세가지 전반적인 목적에 의해 기술된다:

어떤 사람들은 추가적인 보안 목적을 정의하는 반면 다른 사람들은 이러한 추가적인 목적을 위 세가지 목적의 특별한 경우로 일률적으로 취급한다. 예를 들어 어떤 사람은 부인 방지 (non-repudiation) 를 별도의 목적으로 분류하는데 이는 송신자와 수신자가 나중에 부인할 수 있음에도 불구하고 각각 메시지를 전송 및 수신했음을 ``입증"하는 능력이다. 프라이버시는 때때로 기밀성과 별도로 다뤄지는데 어떤 사람은 이를 데이타 대신 사용자 (예, 그들의 신원) 의 기밀성 보호로 정의한다. 대부분의 목적들은 식별 (identification) 과 인증을 필요로 하는데 이는 때때로 별개의 목적으로 열거된다. 종종 감사 (auditing, 또한 회계 책임 accountability 이라고도 부른다) 도 합당한 보안 목적으로 분간된다. 때때로 접근 제어 (access control) 및 신뢰성 (authenticity) 도 또한 별도로 열거된다. 모든 경우에 있어 이러한 목적들을 어떻게 종합하느냐에 상관없이 이들을 언제 충족시켜야 하는지 알 수있도록 프로그램의 전반적인 목적을 확인하는 것이 중요하다.

때때로 이러한 목적들은 알려진 일련의 위협에 대한 반응으로 때때로 이러한 목적들중 일부는 법에 의해 요구된다. 예를 들어 미국의 은행들 및 다른 금융 기관들에 대해서는 ``Gramm-Leach-Bliley (GLB)'' 법령이라 불리는 새로운 프라이버시 법이 있다. 이 법은 공유되는 개인 정보의 발표와 그 데이타를 안전하게 하는 방법을 명하고 제삼자에 의해 공유될 개인 정보의 발표를 요구하며 기관들이 고객들에게 공유되는 데이타를 선택할 기회를 주도록 정하고 있다 [Jones 2000].

때때로 보안과 어떤 다른 일반적인 시스템/소프트웨어 엔지니어링 원리들간에는 불일치가 있다. 보안은 때때로 ``손쉬운 사용"을 방해할 수 있는데 예를 들어 보안적인 설정을 설치하는 것은 작동하지만 비보안적인 ``평범한" 설정보다 더욱 많은 노력이 들 수도 있다. 종종 이 명백한 불일치는 해결될 수 있는데 예를 들어 문제를 다시 생각함으로써 보안적인 시스템을 또한 사용하기 쉽게 만드는 것은 대개 가능하다. 또한 보안과 추상화 (정보 숨기기) 간에도 불일치가 있는데 예를 들어 어떤 고수준 라이브러리 루틴들이 보안적으로 또는 비보안적으로 구현될 수도 있지만 그들의 설계 스펙은 무엇이라고 말해주지 못할 것이다. 결국 애플이케이션이 보안적이여야 한다면 그렇다고 확신할 수 없는 경우 반드시 스스로 이를 보안적으로 만들어야 한다 - 물론 맞다. 라이브러리는 수정되어야 하며 라이브러리 루틴을 잘못 선택함으로써 손해를 입을 사람들은 바로 사용자들이다.

훌륭한 일반적인 보안 원리는 ``철저한 방어 (defense in depth)"이다; 적소에 매우 많은 보호 메카니즘들 (``계층, layers") 들을 가져야 하며 따라서 공격자가 성공적인 공격을 수행하기 위해 다수의 메카니즘을 무너뜨려야 하도록 설계되어야 한다.