267 lines
8.3 KiB
Markdown
267 lines
8.3 KiB
Markdown
# Data Security
|
|
|
|
## Threats
|
|
|
|
- Accidental Loss
|
|
- Human Error
|
|
- Software Failure
|
|
- Hardware Failure
|
|
- Theft, Fraud, Sabotage
|
|
- Improper Data Access
|
|
- Loss of privacy ( personal data )
|
|
- Loss of confidentiality ( corporate data )
|
|
- Loss of data integrity
|
|
- Loss of availability
|
|
|
|
## Non Computer-Based Controls
|
|
|
|
- Policies, agreements, administrative controls
|
|
- Security policies
|
|
- Contingency plans
|
|
- Personnel Controls
|
|
- Secure positioning of equipment
|
|
- Maintenance agreements
|
|
- Physical access controls
|
|
|
|
## Computer-Based Controls
|
|
|
|
- Backup
|
|
- Periodical copies of database & journal to offline media.
|
|
- Journaling
|
|
- Keeping and maintaining a log file / journal of all changes made to database to enable recovery.
|
|
- Checkpointing
|
|
- Syncro between database and transaction log. Buffers are force-written to storage.
|
|
- Integrity
|
|
- Prevents data invalidity.
|
|
- Encryption
|
|
- Encoding of data by algorithm; renders data unreadable without decryption key.
|
|
- Authorisation
|
|
- Granting of right or privilege, enabling subject legitimate access to a system / object.
|
|
- Authentication
|
|
- Determines the authenticity of a user.
|
|
- Views
|
|
- Dynamic result of one or more relational operations on the base relations to produce another relation.
|
|
|
|
## Authorisation
|
|
|
|
### Authorisation Types for Schemas
|
|
|
|
- Resources: allows creation of new relations
|
|
- Alteration: allows the addition / deletion of attributes
|
|
- Index: allows creation / deletion of indices
|
|
- Drop: allows deletion of relations
|
|
|
|
### Authorisation Types for Data
|
|
|
|
- Read: allows read only access
|
|
- Insert: allows insertion ( not modification ) of new data
|
|
- Update: allows modification ( not deletion ) of existing data
|
|
- Delete: allows deletion of data.
|
|
|
|
### Authorisation Grant Graph
|
|
|
|
- Passage of auth from one user to another may be represented in a grant graph.
|
|
- Nodes = users
|
|
- Root = db admin
|
|
- Edge indicates user granted authorisation for a specific transaction to another user.
|
|
- All edges must be part of some path connecting to the db admin.
|
|
- 
|
|
|
|
If DBA revokes auth from U1:
|
|
|
|
- Auth must be revoked from U4, since U1 no longer has authorisation.
|
|
- Auth must not be revoked from U5, since another auth path exists.
|
|
|
|
## View
|
|
|
|
- Alike to a window, through which data is seen.
|
|
- Creation of a view does not require significant memory, not a new relation.
|
|
- Extremely useful in restricting access to data.
|
|
- Users can be given authorisation on views, without being given any authorisation on the relations themselves.
|
|
- Ability of views to hide data serves to simplify usage of system, and enhance security by allowing users specific access.
|
|
- Combination of relational-level security and view-level security can be used to limit, precisely, user access.
|
|
- To create a view, a user must have read auth on all relations the view accesses.
|
|
|
|
### Example
|
|
|
|
Suppose a bank clerk needs to know the names of the customers that have a loan and which branch they bank with, but is not authorised to see specific loan information.
|
|
|
|
1. Deny bank clerk direct access to loan relation
|
|
2. Create view to provide necessary information.
|
|
|
|
```SQL
|
|
CREATE VIEW cust-loan AS
|
|
SELECT branchname, customer-name
|
|
FROM borrower, loan
|
|
WHERE borrower.loan-number = loan.loan-num
|
|
|
|
|
|
```
|
|
3. Grant bank clerk access to view
|
|
|
|
The clerk is now authorised to see the result of a query on the view
|
|
```SQL
|
|
SELECT *
|
|
FROM cust-loan
|
|
```
|
|
|
|
If the creator of the cust-loan view has only read auth on borrower and loan, the creator will only have read auth on the view.
|
|
|
|
## Granting Privileges in SQL
|
|
|
|
```SQL
|
|
GRANT <privilege list>
|
|
ON <relation / view name >
|
|
TO <user list>
|
|
```
|
|
|
|
- GRANT statement is used to confer authorisation
|
|
- Lists the privileges to be granted
|
|
- Specifies the relation / view that will be effected
|
|
- Stipulates who is being authorised.
|
|
- user id
|
|
- PUBLIC ( all valid users )
|
|
- role
|
|
- Granting privilege on a view does not imply privilege on any relation.
|
|
- Grantor of privilege must hold the privilege, or be the administrator.
|
|
|
|
### Types of Privilege
|
|
|
|
- SELECT: allows read access
|
|
- INSERT: allows use of INSERT INTO
|
|
- UPDATE: allows use of UPDATE
|
|
- DELETE: allows tuples to be deleted
|
|
- REFERENCES: allows foreign keys to be declared when creating relations
|
|
- ALL PRIVILEGES: used as a short term for all.
|
|
|
|
### Allowing Granting
|
|
|
|
- Users can be allowed to pass a privilege on to other users.
|
|
|
|
```SQL
|
|
GRANT SELECT
|
|
ON branch
|
|
TO U1
|
|
WITH GRANT OPTION
|
|
```
|
|
|
|
- This gives U1 the select privilege on branch and allows U1 to grant this privilege to other users.
|
|
|
|
### Revoking Privilege
|
|
|
|
- REVOKE is used to remove authorisation
|
|
- Lists all privileges to be revokes
|
|
- If list contains ALL, all privileges will be removed
|
|
- Specifies relation or view that will be effected.
|
|
|
|
```SQL
|
|
REVOKE <privilege list>
|
|
ON <relation / view name>
|
|
FROM <user list>
|
|
[RESTRICT | CASCADE]
|
|
```
|
|
|
|
- If same privilege granted twice to same user by different grantors, user may retain privilege after revoke.
|
|
- All privileges that depend solely on privilege being revoked are also revoked.
|
|
- If revoking a privilege from a user causes other users to lose that privilege, the revoke is CASCADED.
|
|
- Cascading can be prevented by specifying RESTRICT
|
|
- With restrict, the revoke command fails if cascading revokes are necessary.
|
|
- If \<user list> includes public, all users lose the privilege, except those granted explicitly.
|
|
|
|
## Roles
|
|
|
|
Roles permit common privileges for a class of users
|
|
Privileges can be granted or revoked from roles
|
|
Roles can be assigned to users, and also other roles
|
|
|
|
### Roles in SQL
|
|
|
|
```SQL
|
|
CREATE ROLE teller;
|
|
CREATE ROLE manager;
|
|
GRANT SELECT ON branch TO teller;
|
|
GRANT UPDATE(balance) ON account TO teller;
|
|
GRANT ALL PRIVILEGES ON account TO manager;
|
|
GRANT teller to manager;
|
|
GRANT teller TO alice, bob;
|
|
GRANT manager TO avi;
|
|
```
|
|
|
|
## Limitations of SQL Authorisation
|
|
|
|
No support for tuple-level authorisation
|
|
All end-users of an application may be mapped to a single user.
|
|
Task of auth in above cases falls on application program
|
|
|
|
- Auth must be performed at an application level, rather than SQL.
|
|
- Checking for absence of loopholes becomes difficult, since it requires reading a larger amount of code.
|
|
|
|
# Tutorial
|
|
|
|
1. Define following terms:
|
|
1. Authentication
|
|
- The process of verifying the authenticity of a user.
|
|
2. Authorisation
|
|
- The process of verifying permission / privilege to access a system / object.
|
|
3. Roles within SQL
|
|
- Permit common privileges for users, allowing groups of user's permissions to be changed.
|
|
2. Explain the following parts of an auth grant graph:
|
|
1. Nodes
|
|
- Nodes represent users
|
|
2. Root Node
|
|
- Root node represents db admin
|
|
3. Edge
|
|
- Edges represent permission grants between users.
|
|
3. Consider the following:
|
|
|
|
What would be the result of U1 revoking auth from U4?
|
|
- U6 would have its privilege revoked, as there is no path to the root node. All other nodes would be unaffected, since they all have a path to the root.
|
|
4. Consider the following:
|
|
|
|
What would be the result of DBA revoking auth from U1?
|
|
- U2, U4, and U6 all have auth revoked, as here is no path to the root.
|
|
5. Suppose a database includes the following relations.
|
|
Student(sNo, sName, sAddress, sLevel, sMno, sPerformance)
|
|
Module(mNo, mTitle, mLevel, mLecturer)
|
|
|
|
1. Users are:
|
|
- Alfred - Authorised to do anything
|
|
- Christian - See and change student details, cannot register or delete
|
|
- Robin - Same auth as christian
|
|
- George - Same auth as Robin
|
|
2. There is another User, Jessica, who can only see final year students and final year modules. Jessica is not authorised to do anything else. Write SQL statements that implement this. Hint: you can use a view to achieve this!
|
|
3. Now suppose that George has now moved to another university and, therefore, should no longer have access to the database. Write SQL statements to implement this.
|
|
|
|
##### Q5 Answers
|
|
|
|
1. .
|
|
|
|
```SQL
|
|
GRANT ALL PRIVILEGES ON student TO alfred;
|
|
GRANT ALL PRIVILEGES ON module TO alfred;
|
|
GRANT select, update ON student TO christian, robin, george;
|
|
```
|
|
|
|
1. .
|
|
|
|
```SQL
|
|
CREATE VIEW studentFinal AS
|
|
SELECT *
|
|
FROM student
|
|
WHERE sLevel = 6
|
|
CREATE VIEW moduleFinal AS
|
|
SELECT *
|
|
FROM module
|
|
WHERE mLevel = 6;
|
|
|
|
REVOKE ALL PRIVILEGES ON student, module FROM jessica RESTRICT;
|
|
GRANT SELECT ON studentFinal TO jessica;
|
|
GRANT SELECT ON moduleFinal TO jessica;
|
|
```
|
|
|
|
1. .
|
|
|
|
```SQL
|
|
REVOKE ALL PRIVILEGES ON * FROM george;
|
|
```
|