21장 보안과 권한관리

데이터베이스 보안 소개

　안전한 데이터베이스 응용을 설계할 때 세 가지 주요 목표가 있다.

• 보안성(secrecy): 권한이 없는 사용자에게 정보가 노출되어서는 안된다.
  • 예를 들어, 한 학생이 다른 학생의 성적을 볼 수 없어야만 한다.
• 무결성(integrity): 권한이 있는 사용자만이 데이터를 수정할 수 있어야 한다.
  • 예를 들어, 학생들이 자기 성적으로 조회할 수는 있지만, 수정할 수는 없어야 한다.
• 가용성(availability): 권한이 있는 사용자의 접근이 거부되어서는 안 된다.
  • 예를 들어, 교수가 성적을 바꾸고자 하는 경우 바꿀 수 있어야 한다.

　이러한 목표를 달성하기 위해서는, 명확하고 일관성이 있는 보안 정책(security policy)을 수립해서 어떤 보안 조치를 취할지를 반드시 기술해야만 한다. 특히 데이터의 어떤 부분을 보호하고 또 어떤 사용자가 데이터의 어떤 부분을 접근할 수 있는지를 결정해야 한다. 다음으로, 건물에 대한 접근 보안 등의 외부 메카니즘뿐만 아니라 사용하고 있는 DBMS와 운영체제등의 보안 메카니즘(security mechanism)을 활용해서 보안 정책을 보장해야 한다. 여기에서 중요한 점은 여러 레벨에서 보안 조치를 강구해야 한다는 것이다.
　뷰(view)는 보안 정책들을 집행할 수 있는 좋은 도구이다. 뷰 메카니즘은 특정 사용자 그룹에 적합한 데이터 집합의 ‘원도우(window)’를 생성하는 데 사용할 수 있다. 뷰는 민감한 데이터에 대해 데이터 자체가 아니라 뷰를 통해 정의된 제한된 버전을 접근하도록 함으로써 해당 데이터에 대해 접근을 제어한다.

접근 제어

　한 기업의 데이터베이스에는 엄청난 양의 정보와 여러 사용자 그룹들을 포함하고 있다. 대부분의 사용자들은 자신의 업무를 수행하기 위해 데이터베이스의 극히 일부분만 접근하면 된다. 사용자들에게 모든 데이터에 대한 무제한적인 접근을 허용하는 것은 바람직하지 않으며, 따라서 DBMS는 데이터에 대한 접근을 제어하는 메카니즘을 제공해야만 한다.
　DBMS는 크게 두 가지의 접근 제어 방식을 제공한다.

• 임의적 접근제어(discretionary access control): 접근 권한(access right), 또는 권한(privileges) 개념과 사용자에게 권한을 부여하는 메카니즘에 기반하고 있다.
  • 권한은 사용자에게 어떤 데이터 객체를 특정 방법(예를 들어, 읽기 또는 쓰기)으로 접근하도록 허락하는 것이다.
  • 테이블 또는 뷰와 같은 데이터베이스 객체를 생성한 사용자는 자동적으로 해당 객체에 관한 모든 권한을 얻게 된다.
  • 이 후에, DBMS는 이들 권한들이 어떤 사용자들에게 허가(grant)되었고 또 취소(revoke)되었는지를 계속 추적해서, 항상 필요한 권한을 가진 사용자들만 객체를 접근할 수 있도록 보장한다.
  • SQL은 GRANT와 REVOKE명령을 통해 임의적 접근제어를 지원한다.
    • GRANT명령은 사용자들에게 권한을 부여하고, REVOKE 명령은 권한을 회수한다.
  • 임의적 접근제어 메카니즘은 일반적으로 효과적이기는 하나 몇 가지 약점을 가지고 있다. 특히, 권한이 없는 불순한 사용자가 권한이 있는 사용자로 하여금 민감한 데이터를 유출시키도록 속일 수 있다.
• 강제적 접근제어(mandatory access control): 사용자가 개개인별로 변경할 수 없는 시스템 전반의 정책에 기반한다.
  • 이 방식에서는 모든 데이터베이스 객체에게 보안등급(security class)을 부여하고 사용자들마다 허가등급(clearance)을 부여해서, 사용자에 의한 데이터베이스의 읽기와 쓰기에 규칙을 적용한다.
  • DBMS는 어떤 사용자가 어떤 객체를 읽거나 쓸 수 있는지의 여부를 지정하며 사용자가 데이터베이스 객체를 판독하거나 기록하는 것에 대해 몇 가지 규칙들을 만들어 놓는다.
  • DBMS는 객체의 보안등급과 사용자의 허가 등급과 관련한 몇 가지 규칙들에 기반해서 그 사용자가 그 객체를 판독하거나 기록할 수 있는가를 결정한다.
  • 이런 규칙들은 필요한 허가등급을 갖지 못한 사용자에게 민감한 데이터가 절대로 전달되지 않는 것을 보장하도록 한다.
  • SQL 표준은 강제적 접근제어에 대한 지원을 하고 있지 않다.

임의적 접근제어

　SQL은 GRANT와 REVOKE 명령을 통해 임의적 접근제어를 지원한다. GRANT 명령은 사용자들에게 기본 테이블(base table)이나 뷰에 대한 권한을 부여한다. 이 명령의 구문은 다음과 같다.

GRANT privileges ON object To users [WITH GRANT OPION]

　여기서 객체(object)는 기본 테이블이나 뷰만 고려한다. SQL은 다른 종류의 객체들도 인식 하지만 여기에서는 논하지 않는다. 다음 권한들을 포함한 다양한 권한들을 명세할 수 있다.

• SELECT: ‘object‘로 명시된 테이블의 모든 필드들을 접근(읽기)할 수 있는 권한인데, 추후에 ALTER TABLE 명령을 통해 추가된 필드도 포함한다.
• INSERT(column-name): ‘object‘라는 테이블의 지정된 column에서 (널이 아니거나 기본값도 아닌) 값을 갖는 투플들을 삽입할 수 있는 권한이다.
  • 나중에 추가되는 필드들을 포함하여 모든 필드들에 대해 이 권한을 허가하려면 단순히 INSERT를 사용하면 된다.
  • UPDATE(column-name) 및 UPDATE도 이와 비슷하다.
• DELETE: ‘object‘라는 테이블로부터 투플들을 삭제할 수 있는 권한이다.
• REFERENCES(column-name): ‘object’ 라는 테이블의 명세된 column을 참조하는 외래키를 (다른 테이블에서) 정의할 수 있는 권한이다.
  • 단순히 REFERENCES라고 표기하면 나중에 추가되는 column을 포함한 모든 column들에 대해 이 권한을 부여한다.

　특정 사용자가 허가옵션(grant option)을 포함한 권한을 가지면 그는 똑같은 권한을 GRANT 명령을 사용해서 다른 사람들에게 전달해 줄 수 있다. (이때 허가옵션을 포함할 수도 안할 수도 있다.)
　오직 스키마의 소유주만 데이터 정의문 CREATE, ALTERR, DROP 문장을 실행할 수 있다. 이러한 문장들을 실행시킬 수 있는 권한은 허가할 수도 없고 회수할 수도 없다. 　GRANT 및 REVOKE 명령과 결합해서, 뷰는 관계 DBMS가 제공하는 보안 메카니즘의 중요한 요소이다. 기본 테이불에 대해 뷰를 정의함으로써 사용자들이 접근해서는 안 되는 정보들은 감추고 필요한 정보만 보여줄 수 있다. 예를 들어, 다음의 뷰 정의를 고려해본다.

CREATE VIEW ActiveSailors (name, age, day)
       AS SELECT S.sname, S.age, R.day
          FROM Sailors S, Reserves R
          WHERE S.sid = R.sid AND S.rating > 6

　예제에서 사용되는 스키마는 다음과 같다.

Sailors(sid: integer, sname: string, rating: integer, age: real), Boats(bid: integer, bname: string, color: string) Reserves(sid: integer, bid: integer, day: dates)

　ActiveSailors는 접근할 수 있지만 Sailors나 Reserves 릴레이션을 접근할 수 없는 사용자는 예약을 한 선언의 이름은 알지만, 특정 선원의 예약한 배의 bid는 알 수가 없다.
　SQL에서 권한은 권한식별자(authorization ID)에게 부여되는데, 이는 단일 사용자 또는 사용자들의 그룹을 지칭한다. 사용자는 DBMS를 사용해서 명령을 수행하기에 앞서 자신의 권한식별자와, 많은 시스템의 경우, 그에 해당하는 암호를 입력해야 한다. 따라서 기술적으로 다음에 나오는 예에서 Joe나 Michael 등은 사용자 이름이라기보다는 권한 식별자이다.
　사용자 Joe가 테이블 Boats, Reserves, Sailors을 생성했다고 한다. 이제 Joe가 실행할 수 있는 GRANT 명령의 몇 가지 예는 다음과 같다.

GRANT INSERT, DELETE ON Reserves To Yuppy WITH GRANT OPTION
GRANT SELECT ON Reserves TO Michael
GRANT SELECT ON Sailors TO Michael WITH GRANT OPTION
GRANT UPDATE (rating) ON Sailors TO Leah
GRANT REFERENCES (bid) ON Boats TO Bill

• Yuppy는 Reserves 테이블에 투플을 삽입하거나 삭제할 수 있으며, 또다른 사람이 이와 같은 일을 할 수 있도록 권한을 부여할 수도 있다.
• Michael은 Sailors 및 Reserves 테이블에 대해 SELECT 질의를 실행할 수 있으며 다른 사람들에게 Sailors 테이블에 대한 이 권한을 전달 할 수는 있지만 Reserves 테이블에 대한 권한은 전달해 줄 수 없다.
• SELECT 권한을 갖고서, Michael은 Sailors 및 Reserves 테이블을 접근하는 뷰(ActiveSailors)를 생성할 수는 있지만, ActiveSailors에 대한 SELECT 권한을 다른 사람에게 허가할 수는 없다.

　Michael이 다음과 같이 YongSailors 뷰를 생성했다고 하자.

CREATE VIEW YoungSailors (sid, age, rating)
       AS SELECT S.sid, S.age, S.rating
FROM   Sailors S
WHERE  S.age < 18

　기존 테이블은 Sailors 뿐이고 여기에 대해서는 허가옵션을 포함한 SELECT 권한을 Michael이 가지고 있다. 따라서 Michael은 YoungSailors에 대해서도 허가옵션을 포함한 SELECT 권한을 가지며, Youngsailors에 대한 SELECT 권한을 Eric과 Guppy에게 전달할 수 있다.

GRANT SELECT ON YoungSailors To Eric, Guppy

　이제부터 Eric과 Guppy는 YoungSailors 뷰에 대해 SELECT 질의를 실행할 수 있다. 그러나 Eric과 Guppy는 기반이 되는 Sailors나 Reserves 테이블에 대해 직접 SELECT 질의를 실행할 수 있는 권한을 갖고 있지 않다.
　GRANT에 반대되는 명령으로 기존의 권한을 회수하는 명령이 있다. REVOKE 명령의 구문은 다음과 같다.

REVOKE [GRANT OPTION FOR] privileges
       ON object FROM users { RESTRICT | CASCADE}

　이 명령은 특정 권한을 회수하거나 특정 권한의 허가옵션만 회수하는 데 사용할 수 (GRANT OPTION FOR 절을 사용)있다. RESTRICT와 CASCADE중 하나는 반드시 명시해 주어야 한다.
　REVOKE 명령을 수행할 때 CASCADE 키워드를 같이 사용하면, 현재 REVOKE 명령을 수행하는 사용자가 GRANT 명령을 통해 이전에 허용했던 권한들을 갖고 있는 모든 사용자들로 부터 지정된 권한이나 허가옵션을 철회하는 효과가 있다. 만일 이 사용자들이 허가옵션을 포함해서 권한을 받았고, 그 권한을 다른 사용자들에게 넘겨주었다면, 그 사용자들 또한 권한을 잃게 되는데, 다만 같은 권한을 다른 GRANT 명령을 통해 받은 경우는 예외이다.
　REVOKE 명령에 RESTRICT 키워드를 명세하면, 취소 대상 권한으로부터 유도된 다른 권한들이 없을 경우에만 실행되고 유도된 권한이 존재할 경우에는 실행이 거부된다.

강제적 접근제어(Mandatory Control)

　임의적 접근제어 메카니즘은 일반적으로 효과적이지만 몇 가지 약점이 있다. 특히 권한이 없는 불순한 사용자가 권한이 있는 사용자로 하여금 민감한 데이터를 유출시키도록 속일 수 있는 트로이의 목마 방식(Trojan horse scheme)에 취약하다. 예를 들어, 학생 Tricky Dick이 교수 Trustin Justin의 학점 테이블을 훔쳐보고자 한다고 가정하면, Dick은 다음을 수행한다.

• MineAllMine이라는 새로운 테이블을 만들어서 이 테이블에 대해 INSERT 권한을 Justin에게 부여한다.(Justin은 이런 의도를 전혀 모르고 있다.)
• Dick은 Justin이 자주 사용하는 어떤 DBMS 응용 프로그램의 코드를 다음 두 가지 작업을 하도록 수정한다. 우선 Grades 테이블을 읽어서, 그 결과를 MineAllMine에 기록한다.

　그리고는 학점 정보들이 MineAllMine에 복사되기를 기다리기만 하면 되고, 나중에 Justin이 눈치를 채지 못하도록 그 응용 프로그램을 원래대로 복구한다. 이로써, DBMS가 임의적 접근제어를 보장함에도 불구하고 민감한 데이터가 침입자에게 유출된 것이다. Dick이 Justin의 프로그램 코드를 몰래 수정할 수 있는가는 DBMS의 접근 제어 메카니즘 밖의 일이다.
　강제적 접근제어 메카니즘의 목적은 임의적 접근제어의 이러한 단점들을 방지하는 데 있다. 널리 사용되는 강제적 접근제어 모델인 Bell-Lapadula 모델은 다음과 같이 기술된다.

• 객체(Objects)
  • 테이블, 뷰, 투플, 필드 등
• 주체(Subjects)
  • 사용자, 프로그램 등
• 보안등급(security class), 허가등급(clearance)
  • 각 데이터베이스 객체에는 보안등급이 지정되며, 또 각 주체들에게는 보안등급에 대응하는 허가등급이 지정된다.
  • 객체나 주체 A의 등급을 class(A)라고 표시하면 한 시스템 내에 있는 보안 등급들은 하나의 최고 보안등급과 하나의 최저 보안등급을 가진 준순서(partial order)에 따라 조직된다.
  • 네 가지 등급, top secret(TS), secret(S), confidential(C), unclassified(U)를 가정하면, 이 시스템에서는 TS > S > C > U인데, A > B는 등급 A의 데이터가 등급 B의 데이터보다 더 민감하다는 의미이다.

　Bell-LaPadula 모델은 데이터베이스 객체에 대한 모든 읽기와 쓰기에 대해 다음과 같은 구 가지 제약을 가한다.

• 단순 보안 성질(Simple Security Property)
  • class(S) $\ge$ class(O)인 경우에만 주체 S가 객체 O를 읽을 수 있다.
  • TS 등급의 사용자는 C 등급의 테이블을 볼 수 있지만 C 등급의 사용자는 TS 등급의 테이블을 볼 수 없다.
• *-성질( *-Property)
  • class(S) $\leq$ class(O)인 경우에만 주체 S가 객체 O를 쓸 수 있다.
  • 예를 들어, S 등급의 사용자는 S 등급이나 TS 등급의 객체를 쓸 수 있다.

　임의적 접근제어도 명시되면, 이 규칙들은 추가적인 제약들을 표현한다. 그러므로 데이터베이스 객체를 쓰거나 읽기 위해서, 사용자는 (GRANT 명령을 통해 획득한) 필요한 권한을 가지고 있어야 할 뿐 아니라, 사용자와 객체의 등급도 앞의 제약 상황들을 만족해야 한다. 이러한 강제적 접근제어 메카니즘이 어떻게 Tricky Dick의 침입을 막는지 알아보자. grade 테이블을 S로 분류되고 Justin은 S의 허가등급을 가지며, Tricky Dick은 그보다 낮은 허가등급(C)을 가진다고 하면, Dick은 C나 그 이하 등급의 객체들만 생성할 수 있으므로 테이블 MineAllMine에 복사하려고 할 때, class(MineAllMine) $\le$ class(application)이라서 *- 성질을 위반하므로 이 시도는 허용되지 않는다.

다단계 릴레이션과 다중인스턴스화

　강제적 접근제어 정책을 관계 DBMS에 적용하기 위해서는 모든 데이터베이스 객체에 보안 등급을 지정해야만 한다. 객체는 테이블, 투플, 심지어는 칼럼 값의 단위일 수도 있다. 각 투플마다 보안 등급을 지정한다고 가정하면, 이것은 다단계 테이블(multilevel table)의 개념이다. 다단계 테이블은 허가등급이 다른 사용자들이 동일한 테이블에 대해 서로 다른 투플들로 구성된 집합을 의미한다.
　다음과 같은 Boats 테이블의 인스턴스를 고려해 S와 TS 등급의 사용자는 이 테이블의 모든 투플을 보고자 할 때, 두 투플 모두를 볼 수 있다. C 등급의 사용자는 두 번째 투플만 볼 수 있고, U 등급의 사용자는 아무 투플도 볼 수 없다.

　Boats 테이블의 기본 키는 bid이다. 만일 C 등급의 사용자가 투플 <101, Picante, Scalet, C>를 입력하고자 하면, 다음과 같은 딜레마에 빠진다.

• 이 삽입을 허용한다면 테이블에서 두 개의 서로 다른 행이 키 값 101을 갖는다.
• 기본 키 제약조건을 위배하기 때문에, 이 삽입을 허용하지 않는다면, 허가 등급이 C인 이 사용자는 $bid = 101$인 배가 있고, 그 투플의 보안 등급이 C보다 높다라는 사실을 추론할 수 있다. 이는 자신보다 높은 보안등급의 객체들에 대해 어떠한 정보도 추론할 수 없도록 하여야 한다는 원칙을 위배하게 된다.

　이 딜레마는 보안 등급을 키의 한 부분으로 취급함으로써 효과적으로 해결할 수 있다. 따라서 앞의 삽입 연산이 허용되고, 테이블의 인스턴스는 다음과 같이 바뀌게 된다.

　C나 U등급의 사용자는 Picante, Pinto의 투플들만 보게 되지만 S나 TS 등급의 사용자는 세 투플을 모두 볼 수 있다. $bid = 101$인 두 투플을 해석하는 방법은 두 가지가 있다.

• 높은 등급쪽의 투플(S등급인 Salsa)만 실제로 존재한다
• 둘 다 존재하며 그들의 존재가 사용자의 허가등급에 따라 보여진다는 것이다.

　어느 해석을 선택하느냐는 응용 개발자와 사용자에게 달려있다.
　허가등급이 다른 사용자들에게 서로 다른 값을 가지는 것처럼 보이는 데이터 객체가 존재하는 현상을 다중인스턴스화(polyinstantiation)라고 부른다. 개별 column들에 연관된 보안등급을 고려하면, 다중인스턴스롸 개념은 단순한 방법으로 일반화할 수 있지만, 몇 가지 추가적인 사항들이 해결되어야만 한다. 강제적 접근제어 방식의 가장 큰 단점은 너무 엄격하다는 것이다. 보안 정책들이 시스템 관리자에 의해 정해지고, 분류 메카니즘이 충분히 유연하지 못하다. 그렇지만, 임의적 접근제어와 강제적 접근제어를 조합함으로써 효과적으로 사용할 수 있다.

인터넷 응용프로그램의 보안

　DBMS가 안전한 위치에서 접근되는 경우, 사용자를 인증하기 위해서 간단한 암호 메카니즘에 의지할 수 있다. 하지만 단순한 암호 메카니즘보다 훨씬 복잡한 인증 방식이 필요한데, 암호화 기법들은 현재의 인증의 기초를 제공한다.

암호화

　암호화의 기본 아이디어는 사용자나 DBA가 명시한 암호키(encryption key)를 사용해서 데이터에 암호화 알고리즘(encryption algorithm)을 적용하는 것이다. 복호화(decryption) 알고리즘은 암호화된 데이터와 복호화 키(decryption key)를 입력으로 받아서 원래 데이터를 만들어 낸다. 정확한 복호화 키 없이는 복호화 알고리즘은 의미 없는 결과를 만들어 낸다. 암호화 알고리즘과 복호화 알고리즘들 자체는 알려져 있는 반면, 암호키와 복호키 중 하나 또는 둘 다 모두 비밀이다.
　대칭적 암호화(symmetric encryption)에서 암호화 키가 복호화 키로도 사용된다. 대칭 암호화의 가장 큰 약점은 모든 권한이 있는 사용자에게 암호화 키를 알려주어야 하는데, 이는 침입자에게 알려질 가능성이 높다.
　공개키 암호화(public-key encryption)라는 방식에서 각각의 권한있는 사용자들은 모든 사람에게 알려진 공개 암호화 키(publoc encryption key)와 자신만 알고 있는 비공개 복호화 키(private decryption key)를 각각 하나씩 갖고 있다.
　공개키 암호화의 주요 이슈는 어떻게 암호화 키와 복호화 키를 선택하는가이다. 기술적으로, 공개키 암호화 알고리즘은 단방향 함수(one-way function)의 존재에 의존하는데, 이는 그 역을 구하기는 계산적으로 대단히 어려운 함수를 일컫는다. 예를 들어, RSA 알고리즘은 어떤 주어진 숫자가 소수인지 알기는 쉬워도 비소수의 소인수(prime factor)를 구하는 것이 굉장히 힘들다는 점에 기반하고 있다.
　암호화될 데이터가 정수 I라 가정하고 RSA 알고리즘의 아이디어를 개략적으로 알아본다.

• 주어진 사용자의 암호화 키와 복호화 키를 선택할 때, 먼저 암호화해야 될 어떤 수보다도 더 큰 정수 L을 고른다.
• 암호화 키로 숫자 e를 선택하고 e와 L을 기반으로 해서 복호화 키 d를 계산한다.

　다음 계산 방법이 RSA의 핵심이다. L과 e 모두 공개하고, 암호화 알고리즘에 사용된다. 하지만 d는 숨기고, 복호화를 위해 필요하다.

• 암호화 함수는 $S = I^e \mathrm{mod} L$
• 복호화 함수는 $I = S^d \mathrm{mod} L$

　L의 값은 두 개의 큰 서로 다른 소수 p, q의 곱으로 만든다. 암호화 키 e는, 1와 L사이의 임의로 선택한 숫자로써 $(p - 1)*(q - 1)$과 상대적으로 소수 관계이다. 복호화 키 d는 $d \cdot e = 1 mod ((p - 1) \cdot (q - 1))$로 계산된다. 정수론에 따르면, 이렇게 선택된 값들을 이용해서 복호화 함수는 암호화된 버전의 데이터의 원래 값을 복원할 수 있다.
　암호화와 복호화 알고리즘의 매우 중요한 성질은 암호화 키와 복호화 키의 역할이 서로 바뀔 수 있다는 점이다. 많은 프로토콜들이 이 성질에 의존하기 때문에, 단순히 공개키(public key)와 비공개키(private key)로 불린다.

서버 인증하기: SSL 프로토콜

　암호화키와 복호화 키를 Amazon과 연관시켜 생각해본다. 어떤 사용자 Sam이 Amazon의 공개키를 사용해서 주문을 암호화해서 Amazon에 보낼 수 있다. 오직 Amazon만이 이 비밀 주문을 해독할 수 있는데, 왜나하면 복호화 알고리즘은 Amazon의 비공개키를 필요로 하고 비공개키는 Amazon만 알고 있기 때문이다.
　이는 Amazon의 공개키를 신뢰할 수 있는 방법으로 찾는 Sam의 능력에 달려있다. Verisign 등의 많은 회사들이 인증기관(certification authortity)으로 활동하고 있다. Amazon은 공개 암호화 키 $e_A$를 생성하고, 공개키를 Verisign에 보낸다. 그러면 Verisign은 Amazon에 다음 정보를 포함하는 인증서(certificate)를 발송한다.

< Verisign, Amazon, https://www.amazon.com, e_A >

　이 인증서는 Verisign의 비공개키를 사용해서 암호화되는데, 이 비공개키는 웹 브라우저에 알려져 있다.
　Sam이 Amazon 사이트를 방문해서 주문을 하고자 하면, SSL 프로토콜을 사용하는 Sam의 브라우저는 서버에게 Verisign 인증서를 요구한다. 그럼 브라우저는 그 인증서를 Veisign의 공개키를 사용해서 복호화하고 그 결과가 Verisign의 이름을 가진 인증서이고 포함된 URL이 현재 통신하고 있는 서버의 URL과 일치하는지를 확인함으로써, 인증서를 검증한다. 그런 다음에, 브라우저는 임의의 세션키(random session key)를 생성하고, 그것을 Amazon의 공개키를 이용해서 암호화한 후 Amazon의 서버로 전송한다.
　이때부터는 Amazon 서버와 브라우저는 세션키를 사용할 수 있고, AES나 DES와 같은 대칭 암호화 프로토콜을 사용해서 안전하게 암호화된 메시지를 교환할 수 있다. 결국, 브라우저는 Amazon의 공개키를 사용해서 암호화한 Sam의 원래 요청을 갖게 되고, 이를 안전하게 Amazon의 서버에 보낼 수 있다.
　세션키(session key) 없이는 Amazon 서버는 그 정보를 브라우저에게 안전하게 보낼 수 있는 방법이 없다. 세션키의 장점은 대칭 암호화가 공개키 암호화보다 계산적으로 훨씬 빠르다. 세션키는 세션이 끝나면 버려진다.
　안전한 전자 트랜잭션프로토콜(Secure Electronic Transaction Protocol)은 모든 고객이 자신의 공개키와 비공개키를 포함하는 인증서를 모두 획득해야 하고, 모든 트랜잭션에는 Amazon 서버와 고객의 브라우저와 Visa Card와 같이 신뢰할 수 있는 제3기관의 서버가 관여하게 된다.

디지털 서명

　Amzon사의 직원인 Elmer와 McGrawHill사의 직원인 Betsy가 서로 재고(inventory)에 관해서 통신할 필요가 있다고 하면, 공개키 암호화는 메시지 전달의 디지털 서명(digital signature)을 생성하는 데 사용될 수 있다. 즉, Elmer가 Betsy에게서 메시지를 받은 경우, 그 메시지가 정말 Betsy에게서 온 메시지임을 확인할 수 있도록 메시지를 암호화할 수 있고, 나아가서 그 메시지가 Besty가 여행도중 Hotmail 계정을 사용해서 보낸 경우라도 McGrawHill사의 Betsy가 보낸 것임을 증명할 수 있다. Betsy도 Elmer에게서 온 메시지에 대해 마찬가지로 인증할 수 있다.
　암호화 방법을 잘 사용하면 Elmer로 하여금 그 메시지가 정말로 Betsy에 의해 보내졌는지 확인할 수 있다. Betsy는 자신의 비공개키를 사용해서 메시지를 암호화하고 그 결과를 Elmer의 공개키를 사용해서 다시 암호화한다. Elmer가 메시지를 받은 후, 우선 자신의 비공개키로 복호화(decryption)하고 다시 Betsy의 공개키를 사용해서 복호화한다. 이 과정을 거치면 원래의 암호화되지 않은 메시지를 얻을 수 있다. 나아가서 Elmer는 메시지가 Betsy에 의해 작성되고 암호화되었음을 확신할 수 있는데, 왜냐하면 Betsy를 가장한 누군가는 Betsy의 비공개키를 알 수 없고 따라서 최종결과는 의미없는 내용의 메시지가 될 것이기 때문이다. 또한, Elmer도 Betsy의 비공개키를 알지 못하므로 Betsy는 Elmer가 그 메시지를 꾸몄다고 주장할 수 없게 된다. 　발신자 인증이 주 목적이고 메시지 내용을 숨기는 것이 중요하지 않다면, 메시지 서명(message signature)을 사용해서 암호화의 비용을 줄일 수 있다. 서명은 메시지에 단방향 함수를 적용해서 얻을 수 있고, 그 크기는 상당히 더 작을 것이다. 기본적인 디지털 서명 방법에서처럼, 그 서명을 암호화해서 원본과 암호화된 서명을 함께 보낸다. 이때 수신자는 위에서 설명한 방법으로 서명의 발신자를 확인할 수 있고, 메시지 자체는 단방향 함수를 적용해서 서명과 비교함으로써 검증할 수 있다.

보안관련 기타 이슈들

통계 데이터베이스의 보안(Statistical DB Security)

　통계 데이터베이스란 개인이나 사건에 대한 구체적인 정보를 포함하고 있지만, 오직 통계적인 질의만 허용하는 데이터베이스이다. 예를 들어, 선원들의 정보에 관한 통계 데이터베이스를 운용한다고 하면, 평균 등급 값이라던가 최고령 나이 들과 같은 통계적인 질의는 허용하지만 개별 선원에 대한 질의는 허용하지 않는다. 이때 허용되는 통계 질의들의 결과로부터 보호해야할 정보(특정 선원의 등급)를 추론(infer)할 수 있기 때문에, 통계 데이터베이스의 보안은 새로운 문제를 야기한다. 이와 같은 추론의 가능성은 해당 데이터베이스의 보안 정책을 뚫을 수 있는 비밀채널을 의미한다.
　선원 Sneaky Pete가 항해 클럽의 명예 회장인 Admiral Horntooter의 등급을 알고자 하는데, 우연히 Admiral Horntooter가 클럽에서 최고령자인 사실도 알고 있다고 하면, Pete는 “나이가 X보다 큰 선원은 몇 명인가?”라는 질의를 X값을 점차적으로 키워 가면서 결과가 1이 될 때까지 반복 질문한다. 물론 마지막으로 남은 뱃사람은 최고령자인 Horntooter가 된다. 이 질의들은 모두 유효한 통계 질의이기 때문에 허용된다. 이렇게 해서 찾아낸 X 값이 65라 하면, Pete는 “나이가 65보다 큰 모든 뱃사람들 중 최대 등급 값은 얼마인가?”라는 질의를 던진다. 이 질의 또한 통계 질의이기 때문에 허용된다. 그렇지만 이 질의의 결과는 Horntooter의 등급 값을 Pete에게 알려주게 되고, 데이터베이스의 보안 정책이 위배되는 것이다.
　이러한 침입을 막는 한 방법은 관련된 투플들의 수가 최소한 N개 이상인 질의들만 허용하는 것이다. N의 값을 적절히 선택하면 최대 등급에 대한 질의가 실패할 것이기 때문에 Pere는 Horntooter의 정보만 따로 꺼낼 수 없게 된다. 그러나 이러한 제약도 뚫을 수 있다. “나이가 X보다 많은 선원들은 몇 명인가?”라는 질의를 반복적으로 실행하여 시스템이 거부할 때 까지 실행시켜 보면 Pete는 Horntooter를 포함한 N명의 집합을 꺼낼 수 있다. 이 때의 X값을 55라고 하면, Pete는 다음 두 개의 질의를 던진다.

• “나이가 55보다 많은 선원들의 rating 값 합계는 얼마인가?”
  • 나이가 55를 초과하는 뱃사람이 N명이므로 이 질의는 허용된다.
• “나이가 55를 초과하는 선원들 중 Horntooter를 제외하고 대신 선원 Pete를 추가한 선원들의 rating 값 합계는 얼마인가?”
  • Horntooter를 빼고 Pete를 대신 추가했으므로 선원들은 여전히 N과 같기 때문에 이 질의는 허용된다.

　두 질의의 결과 값, 가령 $A_1$과 $A_2$로부터, Pete는 자신의 등급을 알므로 $A_1 - A_2 + Pete`s\,rating$으로부터 쉽게 Horntooter의 등급을 계산할 수 있다.