Infraestructura de Base

de Datos
Jorge Alberto Espinoza Gomez
Introducción

• Que es una Base de Datos?

• Ejemplos de Bases de Datos
• Cual es el sistema de base de datos mas ampliamente usado en el
mundo?
Prerequisitos

• In addition to their professional experience, students who attend

this training should already have the following technical
knowledge:
• Basic knowledge of the Microsoft Windows operating system and its core
functionality.
• Working knowledge of relational databases
• Working knowledge of Transact-SQL.
• Some experience with database design
Instalación Paso a paso de sql server

• Entorno virtual con vmWare WorkStation

• Equipo Windows Server 2012 R2
• Instalación dentro de Active Directory
• SQL Server 2016 Developer Edition
 Authenticating Connections to SQL Server

• Protection of data within your Microsoft® SQL Server® databases

is essential and requires a working
• knowledge of the issues and SQL Server security features.
• This module describes SQL Server security models, logins, users,
partially contained databases, and crossserver authorization.
 Overview

• Security implementation for SQL Server usually begins at the

server level, where users are authenticated, based on logins, and
organized into server-level roles to make it easier to manage
permissions.
• Before learning how to configure security in SQL Server, it will be
useful to explore some basic security concepts, and identify how
they relate to SQL Server.
Securables, Principals, and Permissions

• Security is generally concerned

with allowing someone or
something to access a resource
and to perform one or more
actions on it.

Example, the folder is the

securable, the user is the
principal, and the administrator
must grant the user the “read”
permission on the folder.
Security Hierarchies

• Security architectures are often

hierarchical, primarily to simplify
management of permissions. In a
hierarchical security architecture,
securables can contain other
securables.
• Generally, inherited permissions can
be explicitly overridden at different
hierarchy levels, to fine-tune access. for example, a folder can contain files,
and principals can contain other principals
Best Practice

• Provide each principal with only the permissions they actually

need.
• Use securable inheritance to minimize the number of implicit
permissions that must be set to enable the required level of
access.
• Use principal containers, such as groups or roles, to create a layer
of abstraction between principals and permissions to access
securables.
SQL Server Authentication

• Authentication is the process of ensuring that a principal is who,

or what, they state they are so they can use one or more services.

• Authentication mode:
• Windows®
• Mixed
Windows Authentication

• SQL Server checks the provided user name and password against
the Windows user details. SQL Server does not require a password.
This is the default authentication mode. Windows user security
controls access to SQL Server.
• Kerberos security protocol is used to provide security policies such
as account locking, strong passwords, and password expiration.
The Kerberos protocol is supported by SQL Server over the TCP/IP,
named pipes, and shared memory communication protocols
• Best Practice: If possible, Windows authentication should be used.
SQL Server Authentication (Mixed Mode)

• Mixed mode is the addition of SQL Server authentication to

Windows authentication.
• SQL Server authentication requires a login when the application is
started. The user name and password are stored within database
tables, and so are separate from the Windows authentication.
• The following optional policies can be applied:
• Change Password at Next Login. This feature is enabled in SSQ Server
Management Studio.
• Password Expiration. You can set a maximum age policy for passwords.
• Windows Password Policy. You can enforce Windows policies for passwords
 Practica de Authenticacion
1. Conectarse al SSMS
2. Expandir Seguridad, luego expandir
Logins
3. Clic en el botón derecho y seleccionar
New Logins
4. Login Name: sqlUser1
5. Seleccionar “SQL Server
Authentication”
6. Password: Pa$$w0rd
7. Quitar check “Enforce Password
Policy”
8. Default Database: AdventureWorks
9. User Mapping Page:
- Select AdventureWorks
- Database Role: roleRH
10.Ok
USE [AdventureWorks]
--De acá en adelante se ejecutara como el usuario sqlUser1
SETUSER 'sqlUser1'
-- tiene permiso para ejecutar SELECT sobre esta tabla
SELECT * FROM [HumanResources].[Department]
-- En Person.Address no tiene permiso
SELECT * FROM [Person].[Address]
Authorizing Logins to Connect to Databases

• After creating a login, you should give that login access to at least
one database before they can connect to the server. Generally,
you only need to enable logins to access the databases that they
need to work with. You can do this by creating a database user for
the login in each database that it must access.
• Granting Access to Databases
• Logins cannot connect to a database to which they have not been
granted access. To grant access to a principal, you can create a
database user.
Granting Access to DataBases
Managing Mismatched Security Identifiers

• When you create a SQL Server login, it is allocated both a name

and a security identifier (SID). When you then create a database
user for the login, details of both the name and the SID of the
login are entered into the sysusers system table in the database. If
the database is then backed up and restored onto another server,
the database user is still present in the database—but there might
be no login on the server that matches it. If you then create a new
login with the same name and map as a user in the database, it
will not work. This is because the new login has a different SID to
the original login—so it cannot be added to the database.
Usuarios Especiales
• dbo User
• The dbo user is a special user who has permissions to perform all activities in
the database.
• Any member of the sysadmin fixed server role
• You cannot delete the dbo database user and it is always present in every
database.
• guest User
• The guest user account enables logins that are not mapped to a database user in
a particular database to gain access to that database. Login accounts assume
the identity of the guest user when the following conditions are met:
• The login has access to SQL Server, but not the database, through its own
database user mapping.
• The guest account has been enabled.
Authorization Across Servers (Linked Servers)

• You can execute distributed queries on OLE DB data sources that

are external to the current SQL Server instance. (Microsoft Excel®,
Access® or other database products, such as MySQL or Oracle)
• The benefits of linked servers are as follows:
• External Data Access. Enables access to data that is external
to the SQL Server instance.
• Diverse External Data Sources. You can work with many types
of data sources within your organization.
• Standardized Method. The way you interact with other data
sources is standardized.
Laboratorio

• Crear un Login Usando SQL Server

• Crear un Login usuando Windows authentication (MegaSoft\
Estudiante1)
Assigning Server and Database Roles

• Using roles simplifies the management of user permissions. With

roles, you can control authenticated users’ access to system
resources based on each user’s job function—rather than assigning
permissions user-by-user, you can grant permissions to a role, then
make users members of roles.
 Working with Server Roles

Server-Scoped Permissions
• Permissions at the server level
generally relate to
administrative actions, such as
creating databases, altering
logins, or shutting down the
server.
 Ejemplos
WITH recCTE
SELECT * AS
FROM sys.fn_builtin_permissions('SERVER') (
ORDER BY permission_name; SELECT permission_name, covering_permission_name AS
parent_permission, 1 AS hierarchy_level
FROM sys.fn_builtin_permissions('SERVER')
WHERE permission_name = 'CONTROL SERVER'
UNION ALL
SELECT bp.permission_name, bp.covering_permission_name,
hierarchy_level + 1 AS hierarchy_level
FROM recCTE AS r
CROSS APPLY sys.fn_builtin_permissions('SERVER') AS bp
WHERE bp.covering_permission_name = r.permission_name
)
SELECT * FROM recCTE
ORDER BY hierarchy_level, permission_name;
Typical Server-Scoped Permissions

• CONTROL SERVER
• This permission implicitly grants all other server-level permissions.
• CONTROL SERVER is not exactly equivalent to membership of the sysadmin
fixed server role; some system stored procedures and functions require
membership of the sysadmin role.
• ADMINISTER BULK OPERATIONS
• This permission grants access to bulk insert operations.
• ALTER ANY DATABASE
• This permission grants administrative control over all databases on a SQL
Server instance. It implicitly grants the CREATE ANY DATABASE permission.
Typical Server-Scoped Permissions

• CREATE ANY DATABASE

• This permission grants the right to create new databases.
• ALTER ANY LINKED SERVER
• This permission grants administrative control over all linked servers.
Overview of Fixed Server Roles

• Fixed server roles are preconfigured roles that correspond to

common administrative areas of responsibility for a SQL Server
installation.
• They are provided for convenience of use, and for backward
compatibility with previous versions of SQL Server.
• Each fixed server role is granted a group of permissions relevant to
the function of the role; the permissions granted to a fixed server
role cannot be changed.
Server Roles
Server Roles
Tips

• To keep to the principle of least privilege, you should avoid using

fixed server roles as far as possible.
• Unless a fixed server role holds exactly the permissions required
for a server principal, you should create a user-defined server role
with only the permissions that the principal requires.
• Unlike in some earlier versions of SQL Server, in SQL Server 2016
the BUILTIN\administrators and Local System (NT AUTHORITY\
SYSTEM) accounts are not automatically added as members of the
sysadmin role, although you can add them manually if required.
Public Server Role

• Best Practice: Controlling access to

securable server objects by granting
additional permissions to public is
not recommended, because doing so
might inadvertently grant more
access to every login than is
intended. For the same reason, you
should regularly review the
permissions granted to the public
role.
Fixed Database Roles

• Each database includes

built-in fixed database level
roles with predefined rights
for you to assign privileges
for common scenarios.
Fixed Database Role
Fixed Database Role
Tips

• To keep to the principle of least privilege, you should avoid using

fixed database roles as far as possible. Unless a fixed database
role holds exactly the permissions needed for a group of database
principals, you should create a user-defined database role with
only the permissions the principals require.
• To view membership of database-level roles you can query the
sys.database_role_members system view:
SELECT rdp.name AS role_name, rdm.name AS member_name
FROM sys.database_role_members AS rm
JOIN sys.database_principals AS rdp
ON rdp.principal_id = rm.role_principal_id
JOIN sys.database_principals AS rdm
ON rdm.principal_id = rm.member_principal_id
ORDER BY role_name, member_name;
User-Defined Database Roles

• When you want finer-grained control over permissions on database

objects than is offered by the fixed database roles, you can define
your own database roles and grant them only the permissions they
need.
• Managing database-level roles is similar to managing server-level
roles.
• You can create user-defined database-level roles by using SSMS or
the CREATE ROLE statement.
Demostración de Creación de Roles

• Empleando el management
Studio
• Empleando T-SQL
Próximo Encuentro

• Prueba Escrita de valor 20 pts