데이터베이스

13. 무결성, 보안, 회복

무결성

데이터의 정확성 또는 유효성을 의미

• 동적인 DB에서 데이터의 정확성을 유지하는 것은 어렵다.
  • 그래서 무결성 규칙을 정해놓았다.
    • 이에 위배되지 않으면 무결성은 유지되는 것

무결성 규칙

• 도메인 무결성 규칙
  • 애트리뷰트의 값이 애트리뷰트가 정의된 도메인에 속한 값이어야 한다.
• 릴레이션 무결성 규칙
  • 한 투플이 릴레이션에 삽입이 가능한가
  • 릴레이션과 또 다른 릴레이션 투플들의 관계가 적절한가
  • 이게무슨말이지??
    • 참조 무결성을 지켜야한다.. 라는 의미!

SQL에서 무결성 규칙을 정의하는 방법

아래의 방법으로 가능하다.

• 애트리뷰트 제약 조건
• 기본 테이블 제약 조건
• 주장

애트리뷰트 제약 조건

CONSTRAINT 제약조건이름 CHECK 조건식

ex) 봉급은 정수 60보다 작아야한다.

create table 종업원(
    이름 char(10)
    봉급 integer check (봉급 <60)
)

기본 테이블 제약 조건

• 테이블을 정의할 때 기본 키 외래키 애트리뷰트 조건등을 규정

주장

• 제약 조건을 위반하는 연산이 수행되지 않도록 하는 것

• 근데 대부분 DBMS들이 이걸 지원하지 않음

• 제약 명세: CREATE ASSERTION 이름 CHECK 조건식;

• 제약 제거: DROP ASSERTION 이름;

ex) 모든 과목의 학점은 최소 1학점이어야 한다

CREATE ASSERTION MIN CHECK ((SELECT MIN(과목.학점) FROM 과목) > 0 );

• 주장이 위배되지 않는 경우 데이터베이스의 수정을 허용한다.

트리거

위의 세가지 형태의 규칙을 위반할 때는 그냥 트랜잭션을 취소시키면된다.
하지만 취소 외의 다른 조치도 취할 필요가 있을 시 트리거를 사용한다.

트리거

• 테이블에 어떤 일이 일어나면 자동으로 실행된다
  • 테이블에 삽입,수정,삭제 등 이벤트가 발생할 때 작동
• stored procedure와 비슷한 모양
  • 하지만 해당 테이블에 이벤트가 일어났을 때만 작동
• iN,OUT 매개변수를 사용할 수 없음

즉 데이터를 변경할 때마다 실행되는 특별한 저장 프로시저

• 하나의 테이블과 연관된다.
• 자동적으로 실행된다
• 저장 프로시저와 달리 직접 호출될 수 없다.
• 하나의 트랜잭션이다.

트리거 사용 이점

• DB내 관련 테이블간의 순차적 변경이 가능하다
• CHECK보다 더 복잡한 무결성을 강화
• 사용자 정의 에러 메세지를 정의할 수 있다.
• 비 정규화된 DB에서도 사용될 수 있다
• 변경 시 데이터의 전 후 상태 비교가 가능하다.

트리거 사용시의 고려사항

• 트리거는 실행 후 제약 조건은 실행 전 수행
• 테이블은 한 동작에 대해 여러 트리거를 가질 수 있다.
• 테이블 소유자만이 트리거를 생성, 제거할 수 있다.
• 트리거는 결과 세트를 리턴할 수 없다
• 트리거는 다중 행 동작을 처리할 수있다.

트리거 명세 방법

Ex) 조건이 만족되면 UPdate 자동 실행

create trigger 트리거이름 after insert on 학생  // 학생이 늘어나면 학과테이블에 학생을 추가

BEGIN UPDATE 학과테이블
    SET 학생수 = 학생수 +1
    where 학과코드 = NEW_STUDENT.학과코드;
END;

보안

• 권한이 없는 데이터 접근, 악의적 데이터 파괴 및 유출로부터 DB를 보호
• DB 접근 제어는 여러 수준으로 적용 가능
  • 어떤 사용자는 테이블 검색만
  • 어떤 사용자는 갱신도
• 사용자마다 계정을 부여하고 DB 특정 부분에 특정 작업만을 허용

DBMS 보안 기능

DBMS는 보안에 관해 두가지 기능을 제공함

• DB 접근을 통제
  • 사용자 계정을 관리
  • 접근제어라고한다.
• 특정 사용자에게 지정된 영역만 접근 통제
  • DBMS는 이를 위한 권환 관리 모듈을 가지고 있다.

DBA가 DBS 전체에 대한 보안을 관리하며 이를 위한 권한을 가지고 있다.

• DB 시스템 전체에 대한 보안을 관리
• 사용자들에게 새로운 계정을 만들어 줌
• 사용자에게 권한을 부여, 회수
• 보안 사고시 DB에 대한 감사를 실시

데이터베이스 보안 기법

일반적인 보안기법은 4가지가 있다.

• 권한부여 테이블 사용
• 뷰 기법
• GRANT 기법
• 데이터 암호화 기법

권한 부여 테이블 사용

권한부여 테이블을 이용해 사용자 프로파일을 관리한다.

사용자 프로파일

• 사용자의 권한이 부여된 데이터 객체와 이 객체에 대해 수행시킬 수 있는 연산에 관한 정보
  • 즉 사용자가 쓸 수 있는 테이블과 연산을 저장

권한 부여 테이블

• 모든 사용자의 프로파일을 하나의 테이블로 종합 관리
• T[i,j]
  • 데이터객체 j에 대해 사용자 i가 수행할 수 있는 연산 권한

뷰 기법

뷰의 정의가 그 자체로 권한 부여 기법이 될 수 있다.

• 민감한 정보를 권한이 없는 사용자로부터 은닉시킬 수 있다.
• 간단하고 쉽게 적용이 가능하다.
• 하지만 갱신 삽입 삭제와 같은 연산에 제약이 있다.
  • 원래의 테이블이 뭔지 모른다.
  • 갱신 권한이 있어도 항상 갱신 못하는 제약이 있을 수 있다.

GRANT/REVOKE 기법

• 뷰와 달리 허용된 데이터에 대해 연산 제한이 가능하다.

• 특정 데이터와 연산을 특정 사용자만 수행할 수 있게 권한부여를 명세할 수 있다.

테이블의 생성자

• 테이블을 생성한 유저
• 테이블에 대한 모든 권한(제거 포함)을 가진다
• 권한 일부를 다른 사용자에게 부여할 수 있다.

DBA

• DBMS에 있는 모든 자원 접근 권한을 가짐

DBA나 생성자는 GRANT 문을 사용해 권한일부를 다른 사용자에게 부여 가능하다.

GRANT 명령문

권한 부여 방식

grant 권한리스트 on 객체 to 사용자 WITH GRANT OPTION

• 권한리스트
  • 연산들
• with grant option: 다른 사용자에게 자기가 부여받은 권한 또 다시 부여
  • 권한을 받은 사람이 다른사람에게 이 권한을 줄 수 있다.

권한 회수

REVOKE GRANT OPTION FOR 가져올 권한 on 객체 from 사용자 {CASCADE,RESTRICT}

• GRANT OPTION FOR: 다른 사용자에게 권한을 부여할 수 있게 한 권한을 취소
  • WITH GRANT OPTION을 뺏는다.
  • 사용 권한 자체는 취소되지 않는다.
• CASCADE를 선택하면 연쇄적으로 권한을 다 뺐는다.
  • 권한을 뺐는 애가 준 권한들을 다 뺐는데
    • 이전에 얘가 딴애한테 권한을 받았으면 그 다른 애는 권한이 아직 있다.
• RESTRICT는 권한을 제거할 때 딴 사람에게 영향이 가면 트랜잭션이 실패하도록 한다.
  • 즉 이미 지우려는 사람이 딴 사람에게 권한을 준 경우

ex)

GRANT SELECT,INSERT ON 학생 TO A;
GRANT SELECT ON 학생 TO B WITH GRANT OPTION;
REVOKE SELECT ON 학생 FROM B CASCADE;

데이터 암호화

데이터를 암호로 바꾼다.

• 허가 받지 않은 사람들이 이해할 수 없도록

암호화 시스템

• 암호화 알고리즘(E)
• 암호화 키(K)
• 해독 알고리즘(D)

으로 구성된다.

평문 P

• 전송이나 저장해야할 원시 데이터
  암호문 C
• 암호화된 결과

암호 시스템 구성

C = E^k(P)
P = D^k(C)

• 평문을 암호화 알고리즘과 암호화 키를 이용해 변환한 결과가 암호문
• 암호문을 해독 알고리즘과 암호화 키를 이용해 변환하면 평문

암호화 기법은 다양하다.

전치 암호화 기법

• 문자들을 일정한 간격으로 나누고 위치를 변경시킨다.
• 공백도 문자로 취급한다

대체 암호화 기법

• 평문의 문자를 다른 문자 정보로 대체한다.

DES 기법

• 미국이 대중이 사용할 수 있도록 개발한 암호화
• 대체 암호화 기법과 순열을 사용

공개키 암호화 기법

• 두개의 키를 사용
  • 암호화키와 해독 키
• 암호화키는 공개, 공개키라고도 함
• 해독키는 비밀로 유지

AES 기법

• MYSQL에서 지원됨

테이블을 암호화 하는 방법

• 일반 create문과 똑같이하고 마지막에 ENCRYPTION = 'Y'옵션만넣으면됨

CREATE TABLE test(
    id int,
    txt varchar
) ENCRYPTION = 'Y'

회복

백업

• 현재 데이터베이스를 다른 매체에 보관

회복

• 데이터베이스에 문제가 발생 시 백업 데이터를 이용해 데이터 복원

데이터 저장장치

• 휘발성 저장장치
  • 메인 메모리
  • 시스템 고장시 저장된 정보가 유실됨
• 비 휘발성 저장장치
  • 디스크나 자기테이프
  • 시스템 고장 시에도 저장된 정보는 손실되지 않음
  • DB에서 디스크가 많이 사용
• 안정 저장 장치
  • RAID 시스템
    • 서로 다른 디스크에 블록 사본 저장

데이터 베이스 입출력 연산

데이터베이스는 비휘발성 저장장치에 저장되기 때문에 트랜잭션은 디스크로 부터 메인메모리로 데이터를 입력시키고 다시 디스크로 정보를 출력한다.

연산은 블록단위로 이루어진다.

디스크에 있는 블록을 물리적 블록이라 한다
메인 메모리에 임시 거주하는 블록을 버퍼 블록이라 한다

• 디스크와 메인 메모리 사이 블록이동
  • 디스크가 메인메모리로 인풋 반대는 아웃풋
  • Input
    • 디스크 블록을 메인 메모리로 이동
    • 디스크에서 메인메모리로
      • 사용자의 요구에 의해
  • Output
    • 버퍼 블록을 디스크 블록에 이동시켜 기록
    • 메인메모리에서 디스크로
    • 버퍼 관리자에 의해

장애와 회복 시스템

회복

• 장애가 일어났을 때 데이터베이스를 장애 발생 이전의 일관된 상태로 복원시키는 것

일관된 상태

• 데이터베이스에 오류나 모순이 없는 상태

장애

• 시스템이 정해진대로 작동하지 않는 경우
• 원인
  • 내부적 문제
    • 소프트웨어 결함
    • 하드웨어 결함
  • 외부적 문제
    • 화재, 정전

DBMS 장애에 대비해 회복관리자를 두고 대비한다.

회복의 개념

데이터베이스 회복의 기본 원리는 데이터의 중복 저장이다.

• 다른 곳에 중복 저장했다 장애가 발생했을 때 다시 복원

덤프와 로그

덤프

• 주기적으로 DB 전체를 다른 저장장치로

로그

• DB가 변경될 때마다 데이터의 이전값과 이후 값을 별도의 로그 파일에 저장
• 일지 라고도 한다.

회복 조치의 유형

REDO와 UNDO가 있다.

REDO 재수행

• 데이터베이스 내용 자체가 손상된 경우
• 복사본과 로그 파일을 이용해 복구
  • 최근 덤프받은 복사본을 적재
    • 이 복사본 이후의 일을 로그를 이용해 재 수행해 복구

UNDO 취소

• 변경 중이거나 변경된 내용이 신뢰성을 잃어버린 경우 사용
• 로그 파일을 사용해 모든 변경 사항을 취소
  • DB를 원 상태로 복구

데이터베이스 로그를 이용한 회복

데이터 변경이 발생할 때 마다 생기는 로그 파일을 이용

• 변경한 내용을 언제 반영하느냐에 따라 즉시갱신회복기법과 지연갱신회복기법으로 분류

• 로그를 구성하는 레코드

  • 트랜잭션 ID, 데이터 항목, 이전 값, 이후 값

로그 레코드의 유형

• <Ti,Start>: 트랜잭션 Ti가 시작될 때 기록되는 로그 데이터
• <Ti,X,V1,V2>: 트랜잭션 Ti의 데이터 X를 이전값 V1에서 V2로 변경을 기록하는 로그데이터
• <T1,commut>: 트랜잭션 Ti가 모든 갱신을 성공적으로 완료했음을 나타내는 로그
• <Ti,abort>: 트랜잭션 Ti가 철회되었음을 나타냄, 해당 변경사항 모두 취소

즉시 갱신 회복 기법

데이터 변경이 일어날때 마다 즉시 변경 결과를 DB에 반영

• 로그 파일에도 변경 내용을 함께 저장함

If 트랜잭션 수행 중 실패한다면

• 로그 파일을 참조해 UNDO 수행
  • 트랜잭션이 실행되기 전 상태로 복원
  • 로그 레코드 값 중 이전값이 사용
  • 로그 레코드 형식
    • <트랜잭션 ID,데이터 항목, 이전 값, 이후 값>

수행 과정

1. 트랜잭션 Ti 실행
2. 로그에 <Ti,start> 레코드 기록
3. 트랜잭션이 Wrtie를 하면, 로그 레코드 기록 후 Output 연산
4. Ti가 부분 완료할 경우, 로그에 <Ti,Commmit> 레코드 기록
   • DB가 회복될 수도 있기에 위의 로그를 기록하기 전 DB가 갱신되면 안됨
   • Output(B)가 실행되려면 B에 해당하는 로그가 먼저 기록된 후 실행되어야함

즉시 갱신의 회복

• 장애가 일어나면 로그를 참조해
  • 로그에 Ti Start 레코드만 있고 Ti Commit이 없다면 Ti는 Undo 되어야 한다.
  • 로그에 Ti start 레코드와 Ti commit이 있다면 Ti는 Redo 되어야한다.

커밋 되면 Redo, 커밋 되기 전이면 Undo

회복 기법 적용 예

• 트랜잭션 A가 commit 된 후 트랜잭션 B 실행 상황
  • A가 commit되기 직전 시스템 장애
    • A Undo
  • B가 commit되기 직전 시스템 붕괴
    • A Redo, B undo
  • B가 commit 된 후 시스템 붕괴
    • A,B 둘다 Commit

지연 갱신 회복

트랜잭션이 부분완료될때까지 모든 변경 내용을 로그에만 저장, DB에 저장하는 것은 지연한다.

• Commit이 되어야 Output을 한다
• 부분 완료시 로그 파일에 저장된 변경 내용을 모두 DB에 반영
• 트랜잭션 실행 중 장애가 발생하면 로그를 무시하면 됨.
  • Undo 필요 없음
• REDO 만 실행됨
  • 로그 레코드엔 이전 값이 없어도 됨
    • <트랜잭션 ID,데이터항목,변경된 값>으로 로그레코드가 구성

지연 갱신회복 방법

• 트랜잭션 A가 commit 된 후 트랜잭션 B 실행 상황
  • A 트랜잭션이 Commit 되기 전 장애
    • 로그를 무시
    • 아무런 조치 X
      • DB에 output이 되지 않았으므로
  • B 트랜잭션이 commit하기 직전에 시스템 붕괴
    • A 트랜잭션 REDO
  • B가 커밋된 직후 시스템 붕괴
    • A,B 둘다 REDO

검사 시점 회복

로그를 이용하는 회복 기법은 문제가 있다.

• 로그를 전체 분석하는데는 시간이 오래 걸림
• REDO 연산을 다시 한다면 성능적 문제가 있음
  • 할 필요 없는데 다시 해 시스템 낭비

검사 시점 방법을 이용해 위의 문제 해결

• 트랜잭션을 수행하는 동안 일정 간격으로 검사 시점을 생성
  • 해당 검사 시점 이전의 트랜잭션에는 회복 작업이 필요 없다.
    • 해당 검사 시점 이후의 로그만을 회복 대상으로

회복 방식

• 검사 시점 이전의 트랜잭션
  • 성공이 된 것이니 무시
• 검사 시점 이전 시작, 검사시점 이후 장애 시점 이전 트랜잭션의 Commit
  • 검사시점 이후 트랜잭션 로그에 대해 REDO
• 검사 시점 이후 시작, 장애시점 이전 commit
  • 트랜잭션 전체 redo
• 검사시점 이전 시작, 장애시점 이후 Commit
  • 트랜잭션이 완료되지 않았으므로 전체에 대해 UNDO
• 검사 시점 이후 시작, 장애시점 이후 COmmit
  • 트랜잭션이 완료되지 않았으므로 전체에 대해 Undo

미디어 회복

비 휘발성 장치의 내용이 손상되는 경우

기본 개념

• DB 내용 전체를 주기적으로 다른 안전장치에 덤프

• 미디어 장애 발생 시

  • 가장 최근의 덤프를 이용해 일관된 DB상태로 복구
    • 이후 로그를 이용해 복구

  최근: 디스크 이, 삼중화