Mantenga su Data Warehouse seguro,YA! Javier Loria JLoria@PrimusData.net Carlos Loria Carlos@loria.com /in/JavierSQL @JavierSQL https://javiersql.wordpress.com

Silver / Bronze Gold / Organizer Sponsors

Organiza

Carlos Loria Quality Assurance CISYS Pragmatico: El pragmatismo considera al pensamiento un instrumento o herramienta para la predicción, la resolución de problemas y la acción, y rechaza la idea de que la función del pensamiento es describir, representar o reflejar la realidad. Diseño Empatico: El fundamento del diseño empático es la observación y su objetivo de identificar las necesidades latentes del cliente para crear productos que los clientes ni siquiera saben que desean o, en algunos casos, soluciones que los clientes tienen dificultades para prever debido a la falta de familiaridad con las posibilidades que ofrecen las nuevas tecnologías o porque están encerrados en una vieja mentalidad. Agil:

Javier Loria Mentor de Primus Data Arquitecto y Diseñador de Software Conferenciante y Blogger Javier Loria Pragmatico: El pragmatismo considera al pensamiento un instrumento o herramienta para la predicción, la resolución de problemas y la acción, y rechaza la idea de que la función del pensamiento es describir, representar o reflejar la realidad. Diseño Empatico: El fundamento del diseño empático es la observación y su objetivo de identificar las necesidades latentes del cliente para crear productos que los clientes ni siquiera saben que desean o, en algunos casos, soluciones que los clientes tienen dificultades para prever debido a la falta de familiaridad con las posibilidades que ofrecen las nuevas tecnologías o porque están encerrados en una vieja mentalidad. Agil:

Agenda Definiciones Modelo Stride Definiciones y Seguridad Respaldos Encriptados Seguridad a nivel de Fila Enmascaramiento de datos Siempre encriptado Tecnologías Agenda

<Enter course name here> Security is mostly a superstition <Enter course name here> Security is mostly a superstition. It does not exist in nature, nor do the children of men as a whole experience it. Avoiding danger is no safer in the long run than outright exposure. Life is either a daring adventure, or nothing. -- Hellen Keller La seguridad es en su mayoría una superstición. No existe en la naturaleza, ni lo experimentan los hijos de los hombres en su conjunto. Evitar el peligro no es más seguro en el largo plazo que la exposición directa. La vida es una aventura atrevida o nada. La naturaleza de un Data Warehouse es ser un sistema abierto y accesible. El objetivo del Data Warehouse es generalmente hacer que grandes cantidades de datos sean accesibles a los usuarios, habilitándoles extraer información del negocio como un todo. Cualquier restricción de seguridad puede ser vista como un obstáculo a este objetivo y convertirse en una restricción del DW. A data warehouse by nature is an open, accessible system. The aim of a data warehouse generally is to make large amounts of data easily accessible to users, thereby enabling them to extract information about the business as a whole. Any security restrictions can be seen as obstacles to that goal, and they become constraints on the design of the warehouse. It does not exist in nature Hellen Keller © 2007 Solid Quality Mentors

Activos y medio ambiente Confidential Internal Public Disconnected Intranet Extranet Internet Activos y medio ambiente

Definiciones Aplicación Vulnerabilidades Atacante Vulnerabilidades Defectos de software con consecuencias de seguridad Amenazas Riesgos potenciales del software Ataques Intento de dañar o ganar acceso al Sistema Explotación Ataque exitoso Borde de Confianza Donde el nivel de confianza cambia para código o datos Definiciones

Pasos del Modelo Stride Des-componer Aplicación Identificar Objetivos Revisión Aplicación Identificar amenazas Identificar vulnerabilidades Identify Security Objectives The business (or project management) leadership, in concert with the software development and quality assurance teams, all need to understand the security objectives. To facilitate this, start by breaking down the application’s security objectives into the following categories: Identity: Does the application protect user identity from abuse? Are there adequate controls in place to ensure evidence of identity (as required for many banking applications?) Financial: Assess the level of risk the organization is prepared to absorb in remediation, as a potential financial loss. For example, forum software may have a lower estimated financial risk than an Internet banking application. Reputation: Quantify or estimate of the loss of reputation derived from the application being misused or successfully attacked. Privacy and Regulatory: To what extent will the application have to protect user data? Forum software by its nature is public, but a tax preparation application is subject to tax regulations and privacy legislation requirements in most countries. Availability Guarantees: Is the application required to be available per a Service Level Agreement (SLA) or similar guarantee? Is it a nationally protected infrastructure? To what level will the application have to be available? High availability techniques are significantly more expensive, so applying the correct controls up front will save a great deal of time, resources, and money. Application Overview Once the security objectives have been defined, analyze the application design to identify the components, data flows, and trust boundaries. Pasos del Modelo Stride

Modelo de MS para análisis de seguridad Modelo STRIDE

Propiedades de Seguridad ` Authentication Integrity Nonrepudiation Confidentiality Availability Authorization The goal of Information Security is to ensure the Confidentiality, Integrity and Availability of assets from various threats. The CIA Triad. Property Description Authentication: The identity of users is established (or you’re willing to accept anonymous users). Integrity: Data and system resources are only changed in appropriate ways by appropriate people Nonrepudiation: Users can’t perform an action and later deny performing it. Confidentiality: Data is only available to the people intended to access it. Availability: Systems are ready when needed and perform acceptably. Authorization: Users are explicitly allowed or denied access to resources. Propiedades de Seguridad

Amenazas de Seguridad Spoofing Identity Tampering with Data Repudiation Information disclosure Denial of service Elevation of privilege Amenazas de Seguridad

Identity-Spoof Identity Appropriate Authentication Protect secrets Don't store secrets Identity-Spoof Identity

Integrity-Tampering with Data Appropriate Authorization Hashes Digital signatures Message authentication codes Tamper-resistant protocols Integrity-Tampering with Data

Digital signatures Timestamps Audit trails Non-repudiation

Confidentiality- Information disclosure Authorization Encryption Protect secrets Don't store secrets Privacy-enhanced protocols Confidentiality- Information disclosure

Availability-Denial of service Authentication Authorization Filtering Throttling Quality of service Availability-Denial of service

Authorization - Elevation of privilege Run with least privilege Authorization - Elevation of privilege

Amenazas a el Data Warehouse

Agenda Definiciones Modelo Stride Definiciones y Seguridad Respaldos Encriptados Seguridad a nivel de Fila Enmascaramiento de datos Siempre encriptado Tecnologías Agenda

Nuevas Tecnologías y Seguridad Backup with Encryption X Row Level Security Data Masking Always Encrypted - Transparent Data Encryption SQL Audit Resource Governor Data Encryption Spoofing Identity Authentication Tampering with Data Integrity Repudiation Nonrepudiation Information disclosure Confidentiality Denial of service Availability Elevation of privilege Authorization Nuevas Tecnologías y Seguridad

Respaldos Encriptados Backup with Encryption SQL 2014+

Porque encriptar respaldos? Aplicación Atacante Vulnerabilidades Defectos de software con consecuencias de seguridad Amenazas Riesgos potenciales del software Ataques Intento de dañar o ganar acceso al Sistema Explotación Ataque exitoso Borde de Confianza Donde el nivel de confianza cambia para código o datos Porque encriptar respaldos?

Encriptación de Respaldos Generar Master Key * CREATE MASTER KEY Crear Certificado CREATE CERTIFICATE Respaldar Certificado BACKUP CERTIFICATE Respaldo de Base de Datos BAKUP DATABASE WITH ENCRYPTION (…) Encriptación de Respaldos

Respaldo Encriptado

Seguridad a nivel de Fila Backup with Encryption SQL 2014+

Software Multitenancy -> RLS Usuario Usuario The term "software multitenancy" refers to a software architecture in which a single instance of software runs on a server and serves multiple tenants. A tenant is a group of users who share a common access with specific privileges to the software instance. With a multitenant architecture, a software application is designed to provide every tenant a dedicated share of the instance - including its data, configuration, user management, tenant individual functionality and non-functional properties. Multitenancy contrasts with multi-instance architectures, where separate software instances operate on behalf of different tenants. Software Multitenancy  -> RLS

Como controlar acceso por fila? Basado en Filtros (Vistas) Basado en Predicados (Políticas) 2 Methods or RLS in SQL Server: Filter Based (2005+) SQL Server Security Label Toolkit http://sqlserverlst.codeplex.com/ Use views on tables with “labels” to limit access Problem is you have to change the application code and add views (i.e. upgrades are a pain, unsupported applications) Predicate Based (2016 and Azure) Uses functions and policies to apply predicates to the SQL No application code changes and base database schema left intact (i.e. upgrades not impacted very much by RLS) Como controlar acceso por fila?

Conceptos de RLS Función de Predicado Predicado de seguridad Fusión in-line definida de usuario que implementa la lógica de seguridad Puede combinarse con JOINS que usan otras tablas Predicado de seguridad Une a la función de predicado con la tabla y aplica a la función a todos las consultas. Dos tipos de predicado: filtro y bloqueo Política de Seguridad Colección de predicados de seguridad para manejar la seguridad entre múltiples tablas Objective: This slide shows the concepts and components required for implementing RLS. Talking points: Three core concepts are used in Row-Level Security: predicate function, security predicate, and security policy. Predicate function: Row-level filtering of data selected from a table is enacted through a security predicate filter defined as a user-defined, inline table-valued function (iTVF) implementing security logic (for example, returning a row or not, depending on the principal name, role, or other attributes of the calling user). Security predicate: Binds a predicate function to a particular table, applying it for all queries (for example, applying a function that checks for the rep name or rep manager role to an Accounts table). RLS supports two types of security predicates: filter predicates and block predicates. Filter predicates silently filter the rows available to read operations (SELECT, UPDATE, and DELETE). Block predicates explicitly block write operations (AFTER INSERT, AFTER UPDATE, BEFORE UPDATE, BEFORE DELETE) that violate the predicate. Security policy: This is a collection of security predicates for managing security across multiple tables. (For example, you might have an Account policy that applies multiple security predicates to Account-related tables, and an HR policy that applies several security predicates to various HR tables.) Access to row-level data in a table is restricted by a security predicate defined as an inline table-valued function. The function is then invoked and enforced by a security policy. For filter predicates, there is no indication to the application that rows have been filtered from the result set; if all rows are filtered, a null set will be returned. For block predicates, any operations that violate the predicate will fail with an error. Filter predicates are applied while reading data from the base table, and this affects all get operations: SELECT, DELETE (that is, user cannot delete rows that are filtered), and UPDATE (that is, user cannot update rows that are filtered, although it is possible to update rows in such a way that they will be subsequently filtered). Block predicates affect all write operations. AFTER INSERT and AFTER UPDATE predicates can prevent users from updating rows to values that violate the predicate. BEFORE UPDATE predicates can prevent users from updating rows that currently violate the predicate. BEFORE DELETE predicates can block delete operations. The function is then invoked and enforced by a security policy. The policy can restrict the rows that may be viewed (a filter predicate), but does not restrict the rows that can be inserted or updated from a table (a blocking predicate). There is no indication to the application that rows have been filtered from the result set; if all rows are filtered, a null set will be returned. Animation <<first click>> dbo.fn_securitypredicate Animation <<second click>> ADD FILTER PREDICATE dbo.fn@securitypredicate(wing, startTime, endTime) ON dbo.patients Animation <<third click>> CREATE SECURITY POLICY mySecurityPolicy ADD FILTER PREDICATE dbo.fn@securitypredicate(wing, startTime, endTime) ON dbo.patients Animation <<third click>> Performance? Conceptos de RLS

Seguridad a Nivel de Fila

Enmascaramiento de datos Backup with Encryption SQL 2014+

Dynamic Data Masking – DDM SELECT TOP 1 NumeroTarjeta FROM Customers XXXX-XXXX-XXXX-2464 DDM can be used to hide or obfuscate sensitive data, by controlling how the data appears in the output of database queries. It is implemented within the database itself, so the logic is centralized and always applies when the sensitive data is queried.  Dynamic Data Masking – DDM

Sintaxis y Opciones - DDM , CreditCard VARCHAR(20) MASKED WITH (FUNCTION = 'partial(0,"XXXX-XXXX-XXXX-",4)') NOT NULL Default String: XXXX Numeric: 0 Dates: 01.01.2000 Email aXXX@XXXX.com Partial CXXXXXXXXXX (Prefix, Padding, Suffix) Random 573 (start range, end range) ALTER TABLE Customers ALTER COLUMN CreditCard ADD MASKED WITH (FUNCTION = 'partial(0,"XXXX-XXXX-XXXX-",4)'); GRANT UNMASK TO MUser; Sintaxis y Opciones - DDM

DYNAMIC DATA MASKING

Aplicación Atacante Como usar DDM?

Mejor Forma: Función en Línea y Vistas

Siempre encriptado Always Encrypted SQL 2016+

Qué es siempre encriptado? Server & Tools Business 9/11/2018 TCE-enabled ADO.NET Apps SQL Server Encrypted query No app changes Master key Columnar key Objective: this slide summarizes Always Encrypted and its benefits. Talking points: Always Encrypted makes encryption transparent to applications. An Always Encrypted-enabled driver installed on the client’s computer achieves this by automatically encrypting and decrypting sensitive data in the client application. The architecture for Always Encrypted has the application performing the column-level encryption prior to the confidential columns being sent to SQL Server. The actual encryption is done by the ADO.NET drivers on an application or client machine. When a .NET application sends plain text data to ADO.NET, it’s encrypted prior to sending it to SQL Server. The only change to storing encrypted data that the application needs to make is to change the connection string to indicate column encryption is enabled. When column encryption is enabled, ADO.NET will encrypt Always Encrypted columns prior to sending the data to SQL Server, and will decrypt Always Encrypted columns when they are read from SQL Server. The diagram on the slide shows this architecture. Benefits When it comes to mission-critical security, we have a unique encryption technology that protects data at rest and in motion, allowing data to be fully queried while encrypted. The new ADO.NET library provides transparent, client-side encryption, while SQL Server executes T-SQL queries on encrypted data. The master keys stay with the application and not with the SQL Server. This can work on-premises or via SQL Server in Azure Virtual Machines. So think about the hybrid scenarios in which you want to take advantage of Azure cloud computing, keeping in mind that certain data cannot take advantage of cloud scale due to data security requirements.  Always Encrypted allows organizations to encrypt data at rest and in use for storage in Azure, in order to enable delegation of on-premises database administration to third parties or reduce security clearance requirements for their own DBA staff. As a result, Always Encrypted provides a separation between those who own the data (and can view it) and those who manage the data (but should have no access). Qué es siempre encriptado? © 2015 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

Encryption Types Randomized encryption Encrypt('123-45-6789') = 0x17cfd50a Repeat: Encrypt('123-45-6789') = 0x9b1fcf32 Allows for transparent retrieval of encrypted data but no operations More secure Deterministic encryption Encrypt('123-45-6789') = 0x85a55d3f Repeat: Encrypt('123-45-6789') = 0x85a55d3f Allows for transparent retrieval of encrypted data and quality comparison (for example, in WHERE clauses and joins, distinct, group by) Objective: this slide gives you an overview of the types of encryption for Always Encrypted and the difference between randomized and deterministic encryption.   Talking points: Always Encrypted supports two types of encryption: randomized encryption and deterministic encryption. Randomized encryption uses a method that encrypts data in a less predictable manner. Randomized encryption is more secure, but prevents equality searches, grouping, indexing, and joining on encrypted columns. Deterministic encryption uses a method that always generates the same encrypted value for any given plain text value. Using deterministic encryption allows grouping, filtering by equality, and joining tables based on encrypted values, but can also allow unauthorized users to guess information about encrypted values by examining patterns in the encrypted column. This weakness is increased when there is a small set of possible encrypted values, such as true/false, or north/south/east/west region. Deterministic encryption must use a column collation with a binary2 sort order for character columns. Use deterministic encryption for columns that will be used as search or grouping parameters, for example, a government ID number. Use randomized encryption for data such as confidential investigation comments—which are not grouped with other records or used to join tables—from the row that contains the encrypted column of interest. Encryption Types

Siempre Encriptado

Agenda Definiciones Modelo Stride Definiciones y Seguridad Respaldos Encriptados Seguridad a nivel de Fila Enmascaramiento de datos Siempre encriptado Tecnologías Agenda