[컴보] 5강 DB Security

DB - 데이터 콜렉션, 데이터 관계, 민감 데이터 포함, DBMS, 쿼리

DBMS 구조.... - Physical DB, Acuthorization table, Concurrent access tables, Database description table...

관계DB - relation, table, file / tuple, row, record / attribute, column, field / primary key, foreign key, view/virtual table

 SQL - ANSI/ISO standard / create table,view / insert,delete data in table  ...

 

OWASP(Open Web Application Security Problems) top 10

SQL injection 문제가 가장 큰 문제

sql-injection attack

SQL Injection Attack

- 웹 어플리케이션에서 이용되는 form의 user input을 이용. user_input으로 SQL query를 제출할 때 관여

ex) select * from users where user='$usern' AND pwd='$password'일 때 usern을 "M' OR 1=1--"으로 해두면

select * from users where user='M' OR 1=1 --' AND pwd=~~~ 가 되고 user='M' 또는 1=1이므로 항상 참이 되고 -- 이후는 주석 처리가 되어서 users table의 모든 것이 반환

ex2) $usern='M'; drop table users;' 라면 -> 모든 users table을 삭제 -> 모두가 로그인 불가 - DoS 공격에 이용 가능

-> 얕은 대응 : 오직 한 tuple만이 result로 반환되어야 하는데 그렇지 않다면 제대로 되지 않은 결과

 

제대로된 대응(Correct Solution)

- Escape method : 문제가 될만한 문자를 바꿔주기 ex) ' 를 \' 로 바꿔주기. -> escape함수

 

Database Access Control

- 정해야 할 것

 - 전체 데이터베이스를 접근 허용할지 일부만 허용할지

 - 어떤 권한을 가질지(create, insert, delete, update, read, write)

- administrative policies

 - centralized administration : 일부 관리자가 전체 관리(grant, revoke)

 - ownership-based administration : table 생성자가 해당 table 관리(grant, revoke)

 - decentralized administration : ownership-based administration 방법 + 다른 사용자에게 관리 권한을 일정시간 양도 가능

 

SQL Access Controls

- grant : 권한을 다른 유저에게 부여할 수 있는 권한, revoke : 권한을 철회

 

Cascading Authorizations

t=40인 시점에서 Ellen에게 준 권한은 revoke 되지만 t=60 시점에 Frank에게 준 권한은 유효

 

Role-Based Access Control (RBAC)

- application owner, end user, administrator 로 role을 구별.

- role 생성 삭제 기능, role의 권한 정의 기능, user에게 role 할당 취소 기능 필요

 

Inference Attack(유추 공격)

- 공개되어 있는 Non-sensitive data를 가지고 Sensitive data를 추론하는 공격.

추론 공격 예시

 

Inference Countermeasures(추론 대응방안)

- DB design할 때부터 inference detection을 고려 - 쉽지 않음.

- query할 때 inference를 detect -> monitoring해서 추론 가능할 query를 alter(수정)하거나 reject(거절)함. -> 불편초래 -> 쉽지 않음

 

Statistical Database (SDB)

- 추론 공격을 막기 위해 데이터 원본을 주는 대신 통계치(갯수, 평균 등)을 제공

- 2 종류 : pure statistical DB(통계 data만 보유) <-> ordinary DB with statistical access(개별 data 갖고 있지만 통계적 접근만 가능, DAC, MAC, RBAC 접근 제어 사용)

 - 여전히 추론 공격이 가능할 수 있음

SDB 예시

그러나 데이터 수가 적거나 domain size가 작으면 문제 발생 가능 - ex) EE는 Female이 한명 뿐이라 통계값에서 민감 정보인 GP 값이 추론 가능

 

Statistical DB Security

- characteristic fomula C 이용 : ex) C = (Sex=Male) AND ((Major=CS) OR (Major=EE)) (but set X(C)가 작으면 문제)

 

Other Query Restrictions

- query set overlap control : 이전 query와 새로운 query이 겹치는 것을 제한. -> 겹치는 부분으로 추론 가능하므로

- partitioning : record를 clustering 해서 상호배제적인 그룹으로 나눔. -> 각 그룹에 대해서만 통계적 특정을 query 가능

- query denial & information leakage : query를 거절한다는 그 자체가 추론을 위한 정보 누출이 될수 있음.

 

 Protecting Against Inference

Perturabtion 방식

Perturbation

- original data에 의해 생성된 statistics에 noise를 추가

- data perturbation technique : 원본 SDB에서 noise를 추가한 perturbation된 새로운 DB를 생성

- output perturbation technique : 결과를 반환할 때 noise를 추가한 perturbation된 결과를 반환

- goal = original data와 perturbed result의 통계적 차이를 최소화 -> 주요 chalenge는 perturbed result의 error size의 평균을 정하는 것

- 방식 : Data Swapping 

Data Swapping

 

Database Encryption

- DB엔 중요한 정보가 많기 때문에 보안이 중요 -> 여러 layer의 security로 보호 : firewalls, authentication, O/S access control systems, DB access control systems, database encryption

- Sensitive data의 경우 반드시 암호화가 되어야 함. - 전체 DB 대상으로 할 것인지, record level로 할 것인지, attribute level로 할 것인지 아니면 individual field level로 할 것인지 정해야 함.

- 암호화의 단점 : key management를 어떻게 할지가 어렵다, inflexibillity - processing query를 하기 원할x

순서 : 1) 쿼리 요청 -> 2) 쿼리 프로세서에서 메타 데이터를 기반으로 처리 -> 3) 변환된 쿼리를 서버의 query exceutor에 전송 -> 4) 암호화 DB에서 데이터 추출 -> 5)암호화 된 결과를 Client로 반환 -> 6) Client에서 복호화 -> 7) 평문 반환

 

Abstract Model of a Relational DB

쿼리를 처리하기 위해선 전체 DB를 복호화 해야 하므로 처리 속도가 늦다.

Index를 통해 처리

 

Index 사용 예시 - 비슷한 범위끼리 묶어서 해당 Index의 부분만 복호화해서 성능 향상

 

Cloud Security

Cloud Security Risks

- Cloud Security Alliance(CSA10) list의 클라우드 보안 위협

1) Cloud computing의 남용

2) Interface나 API의 insecure

3) 악성 내부자(malicious insiders)

4) 공유된 기술 문제(shared echnology issues)

5) data 누락 or 누출

6) 계정이나 서비스 하이재킹

7) unknown risk profile

- 클라우드의 unique한 risk에 대응, 클라우드 환경 특징 고려 필요

-> multi-instance model(가상머신을 써서 하나의 DBMS가 여러 DB를 처리, 자기 데이터는 admin 권한으로 접근 가능해야 함) -> multi-tenant model(하나의 장비에 여러 명이 가상으로 공유하고 있기 때문에 잘 처리, 사용자는 배제적으로 사용한다고 보여지기 때문에 보안을 잘 유지)