Bài giảng "Bảo mật cơ sở dữ liệu - Chương 9" trình bày các nội dung: Introduction to SQL encryption, can we offer better performance, service provider architecture, searching over encrypted data, building the index,... Mời các bạn tham khảo.
AMBIENT/
Chủ đề:
Nội dung Text: Bài giảng Bảo mật cơ sở dữ liệu: Chương 9 - Trần Thị Kim Chi (Phần 1)
- Phần I
Pag. 1
- ReView
2 Database Security and Auditing
- Introduction to SQL Encryption
• Encryption hierarchy is marked by three-level security.
• These three levels provide different mechanisms for
securing data across networks and local servers.
• Different levels of hierarchies allow multiple instances
of services (e.g., SQL Server Services) to run on one
physical server.
– Windows Level – Highest Level – Uses Windows DP API for
encryption
– SQL Server Level – Moderate Level – Uses Services Master
Key for encryption
– Database Level – Lower Level – Uses Database Master Key
for encryption
Pag. 3
- Introduction to SQL Encryption
There are two kinds of keys used in encryption:
• Symmetric Key – In Symmetric cryptography system, the
sender and the receiver of a message share a single, common
key that is used to encrypt and decrypt the message. This is
relatively easy to implement, and both the sender and the
receiver can encrypt or decrypt the messages.
• Asymmetric Key – Asymmetric cryptography, also known
as Public-key cryptography, is a system in which the sender
and the receiver of a message have a pair of cryptographic
keys – a public key and a private key – to encrypt and decrypt
the message. This is a relatively complex system where the
sender can use his key to encrypt the message but he cannot
decrypt it. The receiver, on the other hand, can use his key to
decrypt the message but he cannot encrypt it.
Pag. 4
- Introduction to SQL Encryption
Pag. 5
- Introduction to SQL Encryption
There are two different kinds of encryptions available in
SQL Server:
• Database Level – This level secures all the data in a
database. However, every time data is written or read from
database, the whole database needs to be decrypted. This is a
very resource-intensive process and not a practical solution.
• Column (or Row) Level – This level of encryption is the
most preferred method. Here, only columns containing
important data should be encrypted; this will result in lower
CPU load compared with the whole database level
encryption. If a column is used as a primary key or used in
comparison clauses (WHERE clauses, JOIN conditions) the
database will have to decrypt the whole column to perform
operations involving those
Pag.columns.
6
- Can we offer better performance?
• We DO NOT fully trust the service provider with
sensitive information
– Encrypt client’s data and store at server
– Client:
• runs queries over encrypted remote data
• verifies integrity/authenticity of results
• Most of the processing work to be done by the server
• Consider passive adversary
– A malicious individual who has access to data but only tries to
learn sensitive information about the data without actively
modifying it or disrupting any kind of services
Pag. 7
- Service Provider Architecture
Pag. 8
- Query Processing 101…
• At its core, query processing consists of:
– Logical comparisons (> ,
- Searching over Encrypted Data
• Want to be able to perform operations over encrypted
data (for efficiency)
SELECT AVG(E.salary)
FROM EMP
WHERE age > 55
• Fundamental observations
– Basic operations do not need to be fully implemented over
encrypted data
– To test (AGE > 55), it might suffice to devise a strategy that
allows the test to succeed in most cases (might not work in all
cases)
– If test does not result in a clear positive or negative over
encrypted representation, resolve later at client-side, after
decryption. Pag. 10
- Searching over Encrypted Data
• Store an encrypted string – etuple – for each tuple in the original
table
– This is called “row level encryption”
– Any kind of encryption technique (e.g., AES, DES) can be used
• Create an index for each (or selected) attribute(s) in the original
table Pag. 11
- Building the Index
• Partition function divides domain values into partitions
(buckets)
• Partition (R.A) = { [0,200], (200,400], (400,600], (600,800],
(800,1000] }
– partition function has impact on performance as well as privacy
– very much domain/attribute dependent
– equi-width vs. equi-depth partitioning
• Identification function assigns a partition id to each
partition of attribute
Pag. 12
- Building the Index
• Mapping function maps a value v in the domain of
attribute A to partition id
Pag. 13
- Storing Encrypted Data
Pag. 14
- Referring back to our example
SELECT AVG(E.salary) FROM EMP WHERE age > 55
• Suppose the partitions on age are as follows: P1 - [20,30);
P2 -[30,40); P3 - [40,50); P4 - [50,60); P5 - [60,100]
• To test (AGE > 55), it suffices to retrieve all data that falls
into partitions that contain at least one employee with age
> 55
– P4 and P5
– These partitions (e g P4) may contain records with age
- Mapping Conditions
• Q: SELECT name, pname FROM employee, project
WHERE employee.pin=project.pin AND salary>100k
• Server stores attribute indices determined by mapping
functions
• Client stores metadata and uses it to translate the query
Pag. 16
- Mapping Conditions
Pag. 17
- Mapping Conditions
Pag. 18
- Mapping Conditions
Pag. 19
- Relational Operators over
Encrypted Relations
• Partition the computation of the operators across client
and server
• Compute (possibly) superset of answers at the server
• Filter the answers at the client
• Objective : minimize the work at the client and process the
answers as soon as they arrive requiring minimal storage
at the client
• Operators:
– Selection
– Join
– Grouping and Aggregation
– Others: Sort, duplicate elimination, set difference, union,
projection Pag. 20
Thêm vào BST
Báo xấu
Download
Vui lòng tải xuống để xem tài liệu đầy đủ
