Activity No.

8
Securing Databases
Course Code: CPE011 Program:
Course Title: Database Management System Date Performed:
Section: Date Submitted:
Name: Instructor:
1. Objective(s):

This activity aims to secure databases using different methodologies.

2. Intended Learning Outcomes (ILOs):

The students should be able to:
2.1 Configure authentication and authorization of database users.
2.2Assign appropriate server and database roles to the users.

3. Discussion :
Database security uses a broad range of security controls to protect databases from illegitimate use and malicious threats and attacks
that can compromise the confidentiality, integrity and availability of the database. Database security is generally planned,
implemented and maintained by a database administrator and or other information security professional. These include restricting
unauthorized access and use by implementing strong and multifactor access and data management controls.

SQL Server provides a security architecture that is designed to allow database administrators and developers to create secure database
applications and counter threats.The SQL Server security framework manages access to securable entities through authentication and
authorization.

Authentication is the process of logging on to SQL Server by which a principal requests access by submitting credentials that the
server evaluates. Authentication establishes the identity of the user or process being authenticated.

SQL Server supports two authentication modes, Windows authentication mode and mixed mode.

• Windows authentication is the default, and is often referred to as integrated security because this SQL Server security model
is tightly integrated with Windows. Specific Windows user and group accounts are trusted to log in to SQL Server. Windows
users who have already been authenticated do not have to present additional credentials.
• Mixed mode supports authentication both by Windows and by SQL Server. User name and password pairs are maintained
within SQL Server.

Authorization is the process of determining which securable resources a principal can access, and which operations are allowed
for those resources. Principals are entities that can request SQL Server resources.Every principal has a security identifier (SID).

SQL Server-level principals

• SQL Server authentication Login

• Windows authentication login for a Windows user
• Windows authentication login for a Windows group
• Server Role

Database-level principals
 • Database User
• Database Role
• Application Role

Permissions in the Database Engine are managed at the server level through logins and server roles, and at the database level
through database users and database roles. To easily manage the permissions in your databases, SQL Server provides several roles
which are security principals that group other principals. Database-level roles are database-wide in their permissions scope.

There are two types of database-level roles: fixed-database roles that are predefined in the database and user-defined database
roles that you can create.

Fixed-database roles are defined at the database level and exist in each database. Members of the db_owner database role can
manage fixed-database role membership.

Fixed-Database Description
role name
db_owner Members can perform all configuration and maintenance activities on the
database, and can also drop the database in SQL Server.
db_securityadmin Members can modify role membership and manage permissions. db_accessadmin
Members can add or remove access to the database for Windows logins,
Windows groups, and SQL Server logins.
db_backupoperator Members can back up the database.
db_ddladmin Members can run any Data Definition Language (DDL) command in a database.
db_datawriter Members can add, delete, or change data in all user tables.
db_datareader Members can read all data from all user tables.
db_denydatawriter Members cannot add, modify, or delete any data in the user tables within a
database.
db_denydatareader Members cannot read any data in the user tables within a database.
QL Server provides server-level roles to help you manage the permissions on a server. These roles are security principals that group
other principals.Server-level roles are server-wide in their permissions scope.Fixed server roles are provided for convenience and
backward compatibility. Assign more specific permissions whenever possible.

SQL Server provides nine fixed server roles. The permissions that are granted to the fixed server roles (except public) cannot be
changed.

Fixed server- Description

level role
sysadmin Members can perform any activity in the server.
serveradmin Members can change server-wide configuration options and shut down the server.
securityadmin Members manage logins and their properties. They can GRANT, DENY, and REVOKE server-
level permissions. They can also GRANT, DENY, and REVOKE database-level permissions if
they have access to a database. Additionally, they can reset passwords for SQL Server logins.

IMPORTANT: The ability to grant access to the Database Engine and to configure user
permissions allows the security admin to assign most server permissions. The securityadmin
role should be treated as equivalent to the sysadmin role.
processadmin Members can end processes that are running in an instance of SQL Server.
setupadmin Members can add and remove linked servers by using Transact-SQL statements. (sysadmin
membership is needed when using Management Studio.)
bulkadmin Members can run the BULK INSERT statement.
 diskadmin The diskadmin fixed server role is used for managing disk files.
dbcreator Members can create, alter, drop, and restore any database.
public Every SQL Server login belongs to the public server role. When a server principal has not
been granted or denied specific permissions on a securable object, the user inherits the
permissions granted to public on that object. Only assign public permissions on any object
when you want the object to be available to all users. You cannot change membership in
public.

Note:public is implemented differently than other roles, and permissions can be granted,
denied, or revoked from the public fixed server roles.
4. Resources:
Personal Computer with installed SQL Server
5. Procedure:

To change security authentication mode

1. In SQL Server Management Studio Object Explorer, right-click the server, and then click Properties.
 2. On the Security page, under Server authentication, select the new server authentication mode, and then click
OK.

3. In the SQL Server Management Studio dialog box, click OK to acknowledge the requirement to restart SQL Server.
4. In Object Explorer, right-click your server, and then click Restart. If SQL Server Agent is running, it must also be
restarted.

Note: It is recommended using Windows authentication wherever possible. Windows authentication uses a series of
encrypted messages to authenticate users in SQL Server. When SQL Server logins are used, SQL Server login names
and passwords are passed across the network, which makes them less secure.
To enable the sa login

Step 1. In Object Explorer, expand Security, expand Logins, right-click sa, and then click Properties.

Step 2. On the General page, you might have to create and confirm a password for the login.
 Step 3. On the Status page, in the Login section, click Enabled, and then click OK.

To create a user login

Step 1. Object Explorer, expand Security, expand Logins, right-click and then choose new Login.
Step 2. On the General page, type the login name and the authentication. Type the password.

Note; If you select SQL server authentication, you can apply any of the three options for the password.

Choose a default database and language. Click OK.

For this activity, use the following:

Login name: User1

Password: user123456
SQL Server Authentication
Check the three options under SQL server authentication

Choose master as default database.

Have you successfully connected to the database engine?(Yes / No).

If No, Explain the procedures to troubleshoot.

Step 3. Disconnect and reconnect the SQL server database engine to test the User1 user login.
To change the server role of a user
Step 1. In Object Explorer, expand Security, expand Logins, right-click a desired user, and then click Properties.

Step 2. On the Server Roles page, check the appropriate server role according to the permission allowed to the user
and then click OK.

Use dbcreator for this activity.

Step 3. Disconnect and reconnect to the SQL server. Choose the user account you previously changed as login. Type
the password and then click Connect.

Step 4. Create a new database SampleDB.

Have you successfully created a database? (Yes / No).
If Yes, explain why.
 Step 5. Create a new user login.
Have you successfully created a user login? (Yes / No).
If No, explain why.

To create a database user

Step 1. In Object Explorer, expand the Databases folder.
Step 2. Expand the database in which to create the new database user.
Step 3. Right-click the Security folder, point to New and Select User

Step 4. On the General page of the Database User- New window, choose one of the user type options from the User
type list.
For this activity, use the following options:
User type: SQL Server with login
User name: User1
Login name: User1
To create a user using T-SQL
Step 1. In the Object Explorer, connect to an instance of Database Engine.
Step 2. On the Standard bar, click New Query.

Step 3. Copy and paste the following example into the query window and click execute.
 Step 4. Verify the database user and login. In Object Explorer, expand SampleDatabase. Choose Security and expand
Users. Check if User2 exists.

6. Database Output

Copy screenshot(s) of your database after completing the procedures provided in Part 5.

7. Supplementary Activity

Do the following tasks and copy screenshot(s) of your output.

1. Create a desired SQL user with login. Make sure that the user login can create another database user and login.
Choose a strong password.
2. Connect to the database engine using the created user login.
3. Create a database CarinderiaDB.
4. Create a user peter that can only create, modify and delete database.
5. Connect using user peter and delete CarinderiaDB.
6. Disable the user sa login.
7. Change the authentication to Windows only.
8. Connect to the database engine using the Windows authentication.
9. Create a desired SQL user with login using T-SQL.

8. Conclusion
9. Assessment (Rubric for Laboratory Performance):