[데이터베이스] 28. 보안 응용

전자 상거래

샘이 아마존에서 상품을 주문하면 TLS (SSL의 새로운 버전) 프로토콜을 사용해서 요청을 암호화하여 보낸다.

이때 암호화를 하는 기본적인 방법은 이전 글에서 정리한 RSA를 사용하여 아마존이 제공하는 공개키를 통해 요청을 암호화한다.

아마존은 수신한 요청을 자신의 비밀키로 복호화하여 내용을 확인하고 처리한다.

따라서 내 요청이 다른 사람에게 탈취당하더라도 다른 사람은 내 요청 내용을 알아낼 수 없다.

 

그런데 아마존이 알려준 공개키를 어떻게 신뢰할 수 있을까?

해커가 자신의 공개키를 대신 보내주고 마치 이게 아마존의 공개키인 것처럼 속일 수도 있지 않을까?

 

그래서 이를 보증하기 위해 verysign 과 같은 인증기관이 등장했다.

이 기관은 이 공개키가 아마존의 공개키가 맞다는 것을 보증해준다.

 

아마존은 인증기관에 자신의 공개키를 전송하면, 인증기관은 아마존에게 (인증기관, 기업명, 도메인, 공개키) 와 같은 정보가 들어있는 인증서를 발급해준다. 이때 인증서는 인증기관의 비밀키로 암호화되어있다.

그리고 웹 브라우저에는 인증기관의 공개키가 기본적으로 내장되어있다.

 

그러면 샘이 아마존에서 상품을 주문할 때 다음 과정으로 주문할 수 있다.

1. 아마존 사이트에게 인증서를 요구한다.

2. 수신한 인증서를 브라우저에 내장된 인증기관 공개키를 사용해서 복호화한다.

3. 복호화한 내용을 보고 내가 요청한 인증기관에 대한 인증서이고, 사이트 주소가 인증서에 기재된 도메인과 같은지 확인한다.

4. 만약 모두 일치한다면 임의의 세션키를 만들고, 인증서 속 아마존의 공개키를 사용하여 '세션 키'를 암호화해서 보낸다.

5. 아마존과 브라우저는 세션키를 이용해 AES, DES 와 같은 대칭키 암호화로 요청을 주고 받는다. (같은 키를 공유해서 이걸로 암호화/복호화) 대칭키 방식이 비대칭키 방식보다 속도가 빠르기 때문이다.

 

---

 

그렇다면 거꾸로 아마존은 샘을 믿을 수 있을까?

샘이라고 주장하는 사람이 샘의 신용카드를 도용해서 대신 결제하려고 하는 것은 아닐까?

 

그래서 아마존은 너가 샘이라는 것을 증명하라는 뜻에서 '로그인' 을 요구한다.

그리고 로그인에 성공해서 신원확인이 되면 그때부터 세션키를 사용하여 대칭키로 암호화된 메세지를 주고받을 수 있다.

 

그렇다면 다시 샘은 아마존이 내가 제공한 신용카드 정보롤 도용하지 않을 것이라는 것을 어떻게 신뢰할 수 있을까?

이런 문제를 해결하기 위해서 secure electronic transaction protocol 이 등장했다.

이 프로토콜을 사용하면 비자, 마스터카드와 같은 해외 결제 대행사와 안전하게 트랜잭션을 주고 받을 수 있다.

 

먼저 모든 고객은 비밀키, 공개키를 포함하는 인증서를 획득한다.

그리고 아마존에 요청을 보낼 땐 신용카드 정보를 제외하고 아마존의 공개키로 암호화하고, 신용카드 정보는 비자/마스터카드의 공개키를 사용해 암호화한다.

 

그러면 서버는 신용카드사의 공개키로 암호화된 내용을 확인할 수 없으므로 비자/마스터카드에 요청을 보내서 이 암호화된 내용이 정말 샘의 카드가 맞는지, 유효한지 검증을 요청한다.

 

비자/마스터카드가 맞다고 검증해주면 아마존은 결제를 진행한다.

 

 

디지털 서명

A와 B가 통신을 하는데, B는 내가 받은 메세지가 정말 A로 부터 온 것인지 확신할 수 없을 수 있다.

이때 디지털 서명을 사용하면, 이 메세지가 A로부터 왔다는 것을 신뢰할 수 있다.

 

먼저 A는 내가 보낼 메세지를 자신의 비밀키로 암호화한다.

그리고 암호화된 데이터를 B의 공개키로 암호화해서 보낸다.

 

B는 수신한 데이털르 자신의 비밀키로 복호화해서 확인한다.

그 내용은 A의 비밀키로 암호화된 데이터이므로 (블록체인에선 이걸 'A의 서명' 이라고 표현한다.)

A의 공개키를 사용해서 데이터를 복호화하면 내용을 알 수 있다. (블록체인에서는 이걸 서명 검증이라고 표현한다.)

 

이는 메세지 서명에도 활용될 수 있다.

메세지 서명은 메세지의 암호화가 중요한 것이 아니라, 이 메세지가 정말 내가 쓴 메세지라는 것을 검증하는데 유용하다.

먼저 메세지를 해싱하고, 해싱된 값을 디지털 서명 방식으로 암호화 (나의 비밀키로 암호화 - 상대방의 공개키로 암호화) 해서 '원본 메세지

와 함께' 보낸다. (디지털 서명을 하는 이유는 발신자를 확인하기 위함이다. 해시값만 디지털 서명하는 이유는 해시값의 크기가 원본 메세지보다 작아져서 암호화 비용이 줄어들기 때문이다.)

 

상대방은 암호화된 해시값을 복호화해서 확인한 후, 원본 메세지를 해싱해서 해시값이 일치하는지 확인한다.

해시값이 일치하면 이 원본 메세지가 정말 상대방이 작성한 메세지라는 것을 신뢰할 수 있게 된다.

 

 

 

통계 데이터베이스

데이터베이스의 개별 질의를 허용하지 않고, 오직 데이터에 대한 통계 조회만 허용하는 데이터베이스이다.

(max, min, count 등..)

하지만 통계 질의만으로 일반 선원의 정보를 알아내는 것도 가능하다.

 

A가 B의 등급 데이터를 알고 싶다고 해보자.

이때 A는 B의 나이가 제일 많다는 것을 알고 있다.

 

먼저 A는 통계 데이터베이스에 나이가 X보다 큰 사람이 몇 명인지 X값을 1씩 증가시키면서 물어본다.

그러다가 특정 X 값보다 나이가 많은 사람이 존재하지 않는 순간이 오면 그 순간의 X가 최고령 나이가 된다.

 

이제 A는 통계 데이터베이스에 다음과 같은 질의할 수 있다.

나이가 X보다 많은 사람들의 '최대 등급' 을 알려달라

만약 최고령 사람이 1명만 존재한다면, 사실상 나이가 제일 많은 사람의 등급을 조회하는 것과 같은 동작이므로, B의 등급을 알 수 있게 된다.

 

그럼 통계 데이터베이스 입장에서는 질의의 결과로 N개 이상의 튜플이 나오는 질의만 허용하도록 할 수 있다.

하지만 이 경우에도 집합 연산을 활용하면 뚫어낼 수 있다.

 

먼저 A는 자신과 B를 포함하는 N개의 튜플이 나오는 집합을 구성하고, 이 집합에 대해 질의한다.

첫 번째로 A의 나이가 55세라고 할 때, 나이가 55세를 초과하는 사람들의 등급 합을 질의한다. (A를 제외한 사람들의 등급 합)

두 번째로 A를 포함하고, B를 제외한 나이가 55세를 초과하는 사람들의 등급 합을 질의한다. (이전의 집합에서 B가 빠지고 A가 추가된다.)

 

첫번째 결과가 A1, 두번째 결과가 A2 라고 한다면,

A1 = 다른 사람들의 등급 합 + B의 등급 

A2 = 다른 사람들의 등급 합 + A의 등급

이므로, A1 - A2 + A의 등급을 연산하면 B의 등급을 계산할 수 있다.

 

이 방법이 성공한 이유는 두 질의의 교집합이 한 명의 사람을 제외하고는 모두 같은 교집합에 속했기 때문에 가능한 문제였다.

그렇다면 기존처럼 N개 크기의 집합 제한을 유지하고, 이 집합에 대한 질의의 교집합 크기를 M개로 제한해보자.

그러면 교집합을 제외한 영역의 크기가 넓어지므로, 대조해야할 튜플의 개수가 많아진다.

(N/M에 비례하여 질의 수가 증가한다. M이 증가하면 교집합이 커지므로 질의 수가 감소한다.)

 

따라서 이제는 질의를 한번 한번 반복하면서 튜플들을 대조할 수 있으므로, 최종적으로 질의 횟수를 제한할 수도 있다.

하지만 이것도 완벽할 수 없다. 다른 사람과 협력하여 각자의 질의 횟수를 합쳐서 시도해볼 수 있기 때문이다.

 

 

접근 제어

GRANT

그렇다면 결국 DBMS에 접근할 수 있는 사용자와 접근해서 할 수 있는 행동에 제약을 두는 방법을 고민할 수 있다.

대부분의 DBMS는 이런 접근 제어 기능을 제공한다.

 

접근제어는 다음과 같은 문법으로 작성한다.

 

GRANT preveileges ON table/view TO users [ WITH GRANT OPTION ]

 

이때 부여할 수 있는 권한은 다음과 같이 5가지가 있다.

- SELECT

- INSERT (column-name 명시 가능)

- UPDATE (column-name 명시 가능)

- DELETE

- REFERENCES (column-name 명시 가능) : 명시한 컬럼을 참조할 수 있는 외래키를 다른 테이블에서 정의할 수 있는 권한. 컬럼을 명시하지 않으면 모든 컬럼에 대해 참조 권한을 부여할 수 있다.

 

with grant option을 덧붙이면 GRANT 명령어를 사용하여 다른 사람에게 권한을 전달할 수 있다.

기본 테이블 (최초로 생성된 테이블) 을 만든 유저는 모든 권한을 가지고 있으며, 자신의 권한을 다른 유저에게 나눠줄 수도 있다.

단, 테이블 스키마의 생성/수정/삭제는 테이블의 소유주만 할 수 있다.

 

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, reserves 테이블에 접근할 권한은 없지만, ActiveSailors 뷰에 접근할 수 있는 유저가 있다면,

이 유저는 bid, sid는 조회할 수 없지만 뷰를 통해서 선원 이름, 나이, 예약일을 조회할 수 있다.

이렇게 뷰를 사용하면 원본 테이블에서 특정 컬럼을 제외한 나머지 컬럼의 정보만 공개할 수 있다.

 

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

 

사용자 Joe가 sialors, boats, reserves 테이블을 만들고 위와 같이 권한을 부여했다고 해보자.

몇 가지만 살펴보면

 

Yuppy는 예약 테이블에 데이터를 삽입/삭제할 수 있는 권한을 가지며, 자신의 권한을 다른 유저에게 부여할 수도 있다.

미셸은 예약 테이블의 모든 컬럼을 조회할 수 있으나, 자신의 권한을 전달할 수는 없다.

미셸은 선원 테이블의 모든 컬럼을 조회할 수 있으며, 자신의 권한을 전달할 수 있다.

(미셸은 이렇게 예약, 선원 테이블에 대한 조회 권한이 있으므로 위의 ActiveSailors와 같은 뷰를 작성할 수 있다. 하지만 이 뷰에 대한 select 권한은 다른 사람에게 넘길 수 없다. 예약 테이블의 조회 권한을 넘길 수 없기 때문이다.)

레아는 선원 테이블의 rating 필드를 수정할 수 있으나, 권한을 전달할 수는 없다.

빌은 보트 테이블의 bid 필드를 외래키로 참조하는 다른 테이블을 생성할 수 있으나, 이 권한을 넘길 수는 없다.

 

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

 

미셸이 위와 같은 뷰를 정의했다고 해보자.

(미셸은 선원 테이블에 대한 조회 권한을 갖고 있다.)

 

그리고 이 뷰에 대한 조회 권한을 에릭과 구피에게 부여했다고 해보자.

 

GRANT SELECT ON YoungSailors TO Eric, Guppy

 

에릭과 구피는 YoungSailors 테이블에 대한 조회 권한만 가질 뿐, Sailors에 대한 조회권한은 갖지 않는다.

또한 자신의 권한을 다른 유저에게 넘길 수 없다.

 

CREATE TABLE Sneaky (maxrating INTEGER,
	CHECK (maxrating >=
			(SELECT MAX (S.rating)
		 	 FROM Sailors S)))

 

미셸이 테이블을 이렇게 만들었다고 해보자.

그러면 미셸은 레이팅 값을 하나씩 넣어서 생성해보며 생성이 되는 rating 값을 찾아서 최대 rating 을 간접적으로 알아낼 수도 있다.

이런 통계 데이터베이스에서 발생하는 문제와 비슷한 문제를 막기 위해, 테이블을 생성할 때도 select 권한이 있는 사람만 테이블 생성시 제약조건을 추가할 수 있다.

 

Update	Sailors S
SET 	S.rating = 8

 

레아는 선원 테이블의 rating 필드에 대한 갱신 권한이 있으므로 위와 같은 SQL을 실행할 수 있다.

하지만 나이를 수정하는 것은 할 수 없다. 나이 필드에 대한 갱신 권한은 없기 때문이다.

 

Update  Sailors S
SET     S.rating = S.rating – 1

 

한 가지 재미있는 점은 위 SQL도 실행할 수 없다는 점이다.

이 SQL은 기존의 S.rating을 읽고, 그 값을 1 빼서 새로 덮어쓰는 과정을 거친다.

따라서 기존의 S.rating 값을 읽는 Select 권한도 갖고 있어야 실행할 수 있다.

 

CREATE TABLE Reserves (sid, bid,
       FOREIGN KEY (bid) REFERENCES Boats)

 

이번엔 위와 같은 SQL을 빌이 실행한다고 해보자.

빌은 bid에 대한 reference 권한을 갖고 있다.

따라서 문제없이 이 SQL을 실행할 수 있다.

 

GRANT INSERT ON Sailors TO Michael
GRANT INSERT ON Sailors (sid) TO Michael

 

위 2가지 SQL의 차이점은 간단하다.

미셸이 선원 테이블의 모든 필들에 대해 삽입 권한을 갖느냐, sid 필드에만 삽입 권한을 갖느냐의 차이를 가진다.

만약 후자로 작성하되, 모든 필드를 다 명시했다면 어떤 차이가 있을까?

 

선원 테이블을 소유한 빌이 선원 테이블에 새로운 컬럼을 추가했다고 해보자.

이때 첫 번째 방식의 권한 부여는 추가된 컬럼에 대해서도 삽입을 허용한다.

하지만 두 번째 방식의 권한 부여는 추가된 컬럼에 대한 삽입을 허용하지 않는다.

 

 

REVOKE

다음으로 권한을 회수하는 방법을 살펴보자.

기본적인 문법은 다음과 같다.

 

REVOKE [ GRANT OPTION FOR ] privileges ON table/view FROM users { RESTRICT | CASCADE }

 

GRANT OPTION FOR 구문은 선택이다.

만약 추가한다면, 다른 유저에게 권한을 넘길수 있도록 허용하는 옵션만 회수한다.

(기존의 자신이 사용하는 권한은 회수 당하지 않는다.)

 

RESTRICT, CASCADE 옵션은 둘 중에 하나를 반드시 명시해야 한다.

CASCADE는 revoke 명령어를 수행하는 사용자가 grant 명령을 통해 이전에 허용했던 권한을 갖고 있는 모든 사용자로부터 권한/권한 옵션을 회수하는 효과를 갖는다.

RESTIRCT는 revoke 명령어의 대상이 되는 사용자가 다른 권한을 전달한 적이 없다면 정상적으로 취소 되고, 전달한 적이 있다면 취소하지 않는다.

 

GRANT SELECT ON Sailors TO Art WITH GRANT OPTION (by JOE)
GRANT SELECT ON Sailors TO Bob WITH GRANT OPTION (by Art)
REVOKE SELECT ON Sailors FROM Art CASCADE (by JOE)

 

위 SQL을 따라가보면

JOE -> Art 에게 권한 부여

ART -> Bob 에게 권한 부여

JOE -> Art 권한 삭제

 

와 같은 순으로 명령어를 처리하고 있음을 알 수 있다.

이때 조가 아트의 권한을 삭제하면 CASCADE 옵션이 걸려있기 때문에 아트가 밥에게 부여한 권한 역시 삭제된다.

따라서 밥은 선원 테이블을 조회할 수 없게 된다.

 

만약 옵션이 CASCADE가 아니라 RESTRICT 였다면 권한 회수 명령이 실행되지 않았을 것이다.

아트가 밥에게 권한을 전달한 이력이 있기 때문이다.

 

GRANT SELECT ON Sailors TO Art WITH GRANT OPTION (executed by Joe)
GRANT SELECT ON Sailors to Bob WITH GRANT OPTION (executed by Joe)
GRANT SELECT ON Sailors to Bob WITH GRANT OPTION (executed by Art)
REVOKE SELECT ON Sailors FROM Art CASCADE (executed by Joe)

 

이번엔 위 예시를 보자.

선원 테이블에 대한 조회 권한을 아트, 밥에게 부여하고

아트가 또 다시 밥에게 조회 권한을 부여하였다.

이때 조가 아트로부터 CASECADE 옵션을 주고 조회 권한을 회수했다.

 

그렇다면 과연 밥은 조회를 할 수 있을까?

이는 권한 그래프를 그려보면 쉽게 알 수 있다.

 

 

먼저 조가 테이블을 생성했기 때문에, 시스템이 조에게 테이블에 대한 모든 권한을 부여한다.

조는 아트와 밥에게 select 권한을 부여하고, 아트는 밥에게 select 권한을 부여했다.

 

이때 조가 아트의 권한을 CASCADE 옵션을 주고 회수했다면 다음과 같이 회수된다.

 

 

회수된 이후에도 여전히 밥은 조로부터 받은 권한을 갖고 있기 때문에 선원 테이블을 조회할 수 있다.

 

 

GRANT SELECT ON Sailors TO Art WITH GRANT OPTION (executed by Joe)
REVOKE GRANT OPTION FOR SELECT ON Sailors FROM Art CASCADE (executed by Joe)

 

다른 예시로 위와 같이 SQL을 실행하는 경우를 살펴보면

GRANT OPTION FOR 은 권한을 부여할 수 있는 권한만 회수하므로, 아트는 여전히 선원 테이블을 조회할 수 있다.

 

GRANT SELECT ON Sailors TO Art WITH GRANT OPTION (executed by Joe)
GRANT SELECT ON Sailors TO Bob WITH GRANT OPTION (executed by Art)
GRANT SELECT ON Sailors TO Art WITH GRANT OPTION (executed by Bob)
GRANT SELECT ON Sailors TO Cal WITH GRANT OPTION (executed by Joe)
GRANT SELECT ON Sailors TO Bob WITH GRANT OPTION (executed by Cal)
REVOKE SELECT ON Sailors FROM Art CASCADE (executed by Joe)

 

이번엔 이런 상황을 생각해보자.

권한 그래프에 사이클이 있을 때, 회수를 하게 되면 어떻게 될까?

 

 

 

먼저 권한 그래프는 위와 같이 그려진다.

이 상황에서 조가 아트의 권한을 cascade 옵션을 주고 삭제하게 되면

 

 

 

이렇게 권한이 삭제되며, Art 는 여전히 조회 권한을 갖고 있게 된다.

분명 밥이 아트에게 준 권한은 아트에게만 권한을 받았을 때 넘겨주었음에도 삭제되지 않을까?

이건 밥이 Cal로부터 받은 권한이 여전히 남아있기 때문이다.

마찬가지로 아트가 밥에게 준 권한이 남아있는 이유 역시, 아트가 밥에게서 권한을 받았기 때문에 삭제되지 않는다.

 

만약 이 상태에서 추가적으로 CAL의 권한을 CASCADE 옵션을 주고 회수한다면

 

 

 

CAL은 다른 노드로부터 받은 추가 권한이 없으므로 자신이 부여한 다른 권한들을 함께 삭제한다.

하지만 밥과 아트는 서로가 서로에게 권한을 주고 있으므로 남아있게 된다.

 

하지만 이 이후에는 아트와 밥이 가진 권한은 시스템과 연결되지 않았기 때문에 이들의 권한은 다른 노드에게 부여할 수 없으며, 이 둘만 사이클로 갖고있게 되어 권한이 폐기된다.

결과적으로는 Joe만 조회 권한을 갖게 된다.

 

관리자의 예시로 보면

어떤 관리자가 부하직원에게 권한을 부여한 뒤 퇴사했다면,

원래는 (모든 권한 그래프를 다 지우고?) 관리자의 허가 행위를 재실행한 뒤, 그 관리자의 권한만 제거하면 된다.

(부하들이 재귀적으로 권한을 부여한 것은 재실행할 필요 없다.)

(하지만 위 경우에는 굳이 그럴 필요가 없다고 말씀하신 것 같은데 이해를 못햇다..)

 

 

뷰에서의 권한 부여와 회수

뷰를 생성한 사람이 뷰를 생성하는데 사용한 원 테이블의 select  권한을 회수당한 경우, 뷰에 대한 모든 권한을 잃게 되며, 해당 뷰에 대해 권한을 전달받은 사람들도 함께 권한을 회수당한다.

 

만약 뷰를 생성한 사람이 원 테이블에 대한 권한을 추가적으로 얻으면 (select 이후에 update, delete 등도 함께 얻으면) 뷰에 대해서도 자동적으로 해당 권한을 얻게 된다.

 

예를 들어, 조가 미셸에게 선원 테이블 조회 권한을 부여했고,

미셸은 해당 권한을 기반으로 뷰를 생성하면서, 에릭에게 자신이 만든 뷰 조회 권한을 부여했고,

에릭은 해당 권한을 기반으로 또 다른 뷰를 생성했다고 해보자.

 

이때 조가 미셸로부터 조회 권한을 CASCADE로 회수하면 어떻게 될까?

이때는 미셸, 에릭의 모든 SELECT 권한이 회수되므로 둘 모두 뷰도 실행할 수 없게된다.

 

그렇다면 오히려 조가 미셸에게 insert 권한을 추가로 준다면 어떨까?

이때는 미셸이 생성한 뷰에 대해서도 insert 권한을 얻게 된다. (이건 해당 뷰가 갱신 가능할 때만 가능하다.)

또한 미셸은 에릭이 자신의 뷰를 기반으로 생성한 뷰에 대해서도 insert 권한을 얻게 된다.

하지만 에릭은 insert 권한을 추가로 얻지 않는다.

 

만약 insert 권한을 줄 때 WITH GRANT OPTION 을 붙여서 부여했고,

그래서 미셸이 에릭에게도 자신의 뷰에 대해 insert 권한을 부여했다면 어떻게 될까?

이 경우, 미셸은 에릭에게 자신의 '뷰' 에 대해 권한을 주었지만, 뷰에 대한 삽은 기본 테이블에 대한 삽입 권한을 기반으로 주어지기 때문에 기본 테이블에 대한 삽입 권한도 함께 얻게 된다.

 

 

접근 제한 우회와 강제적 접근 제한

학생이 교수의 학점 테이블을 훔쳐보고 싶은 상황을 생각해보자.

학생이 다음과 같이 트로이목마를 이용해 접근 제한을 우회하고자 할 수 있다.

 

1. 학생이 테이블을 하나 생성하고, 이 테이블에 대해 insert 권한을 교수에게 부여

2. 교수가 자주 사용하는 DBMS 스크립트에, 학점 데이터가 자신의 테이블로 복사되도록 하는 스크립트 작성

3. 복사가 끝나면 스크립트를 원복

 

그래서 이 문제를 해결하기 위해 강제적 접근 제한을 둘 수 있다.

 

 

이와 관련하여 책에서는 벨-라파둘라 모델을 소개한다.

이 모델은 권한 부여를 위해 (객체, 주체, 보안등급, 허가등급) 을 명시한다.

이때 등급은 4가지 등급을 부여할 수 있다.

 

이 모델의 보안은 다음 규칙으로 동작한다.

 

1. 사용자의 보안 등급 >= 테이블의 보안등급 이면 조회 가능

2. 사용자의 보안 등급 <= 테이블의 보안등급 이면 삽입/수정/삭제 가능

 

2번이 조금 낯설기는 하지만.. 일단 규칙이 이렇다고 한다.

(왜 높은 등급이 낮은 등급의 테이블에 쓰기를 할 수 없을까)

 

이를 이용해서 트로이 목마 문제를 방지해보면

 

먼저 학점 테이블과 교수에게는 높은 보안 등급을 부여하고, 학생에게는 낮은 보안 등급을 부여한다.

그러면 학생이 학점 테이블을 복사하기 위해 학점 테이블을 조회하려는 순간, 보안 등급 규칙에 위배되기 때문에 조회에 실패한다.

 

 

Reference 에 대한 고찰

조가 보트 테이블을 만들었고, 프레드에게 reference 권한을 주었다고 해보자. (bid 컬럼 한정)

이때는 보트 테이블에 대한 외래키 제약 조건을 갖는 테이블을 생성할 수 있다.

 

만약 reference 권한 대신 select 권한만 있다면 어떨까?

이때는 테이블을 생성할 수 없다.

 

만약 reference 권한을 갖고 있고, 테이블을 만들었는데, 이후에 회수되면 어떨까?

그때는 해당 테이블은 그대로 남아있되, 외래키 제약조건만 사라진다.

 

 

Log4J 취약점

Log4J 라는 자바 진영에서 사용하는 로깅 프레임워크에서 취약점이 발견된 사건

 

 

직접 로깅을 한다면 이렇게 하드코딩으로 일일히 메세지를 작성하고 포맷을 맞춰서 로그 메세지를 작성해야 하는데,

이를 간편하게 할 수 있도록 도와주는 프레임워크다.

 

 

그래서 프레임워크의 동작을 살펴보면 기본적으로는 이렇게 기존 코드를 try - catch 로 감싸고 앞 뒤에 로그 문자열을 출력하는 방법을 채택하였다. (이때 출력 위치는 쉘, 파일, 콘솔 등등 다양하게 설정할 수 있다고 한다.)

 

(패치 이전에는 시스템 제어 권한을 탈취할 수 있었다고 하는데, 고작 로거인데 그게 가능한가? 싶다.

그런데 로거 특성상 관점지향 프로그래밍에 의해 여러 클래스를 넘나들면서 적용되기 때문에 그 부분에서 취약점이 발견된 것 같다..)