Database Security EXPERT
It should be logically organized and professionally done (no spelling errors, clear writing). The lab project must be submitted as ONE DOCUMENT in either WORD OR PDF FORMAT. You might have to alter the tables a bit, create a new table or add rows that can be used to illustrate that your security works. If you don’t want to reuse an old project you have the option of starting from scratch (from a blank sheet of paper). The comments below cover everything I can think of that could be in your project. There are options, e.g., if you can fully implement your security with roles, views, grants, procedures, and triggers you would not have to have any security labels or a VPD. If you implement your security with VPD you might not need any roles, views, or triggers. If you implemented your security with the Oracle Security Labels you might not need any VPD etc. Not every example I give below applies to every project. The lab project report should be as long as it needs to be. I have had reports from 20-30 pages to 160 pages. Long listings of big tables to not add value, but do inflate page length! You probably need less than 10-15 rows in most of the tables. Example of security implementation should be targeted (an update against 1-3 rows not the whole table so that you then demonstrate
It should have sections such as
Introduction
Timeline
Conceptual & Logical Data Model
Physical Design
Implementation
Security
Verification of Database Security Implementation
Introduction:
What is the project about? (A pet store, a small corner supermarket, a
doctor’s office, etc). What are the key users and what are their functions?
(A pet store has an owner, clerks, and maybe an office manger that does
the banking, payroll)
Timeline:
the logical series of steps that must be done and when they must be done
and what order
Conceptual Model:
The functional roles of the various users and database and user
requirements, design assumptions, entity types and relationships, ER
diagram(s), constraints/dependencies,
Logical Model:
Rules Used to Map ER Diagram to Relations, ER-to-Relational Mapping,
Map of ERD to relations (tables), functional dependencies, normalized
relations (should all be 3NF or BCNF) Notional Data Elements for each
Table
Physical Model:
DDL to create basic relations (tables, indexes if any, non security related
triggers, procedures or functions). Security DDL/DML should be in the
security section
Implementation:
Insert statements into Tables, queries to show table populations (Select *)
– you should only have a small number of rows in each table, enough not
to be trivial, but no need to have more that one-five record of each type
(one owner, 2-3 clerks, one office manager, three different types of pet,
etc); examples of the most frequent queries for the business (e.g., what
pets do we have in inventory, what is the cheapest or most expensive pet
(could list by price) what was the payroll last week, month, year)
Security:
The most important section: What is your security plan? What are your
security policies that support that plan? What security procedures will
support the plan and policies? What is your security model? And the
security implementation (users created with passwords, roles created,
privileges granted, views created for security reasons, security triggers,
procedures, functions, labels, etc). Evidence of the implementation (scripts that show the DDL to create the users, grant the privileges, etc and the results (able created, grants affected, etc). Evidence that the security works as it is supposed to (users can do what they are supposed to be able and can not do things that they are prohibited from doing or that they are not explicitly supposed to do
References: If any
Attached is only an example
