블로그 이미지
정홍주
Azure에 대한 내용뿐만 아니라 새로운 트렌드로 빅데이터, BI, SharePoint, 앱 등의 내용을 다룹니다.

calendar

1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31        

Notice

2016.02.19 08:00 Microsft Azure/SQL Databases

 

Azure SQL 데이터 웨어하우스

 

Data warehouse as a Service Azure SQL 데이터 웨어하우스를 알아보겠습니다.

Azure SQL 데이터 웨어하우스의 기본 특징을 나열해보면 다음과 같습니다.

l  몇 초 안에 계산 및 저장소 크기를 확장, 축소 및 일시 중지 가능

l  대규모 병렬 처리(MPP)를 사용한 페타바이트 확장

l  관계형 및 비관계형 데이터간 쿼리 가능

l  Power BI, 기계 학습, HDInsight Data Factory와 원활하게 작동

l  복잡성 감소되고 유지 비용 절감

 

간단하게 생성을 해보도록 하겠습니다. 생성하는 방법은 포털, T-SQL, PowerShell을 통해 생성할 수 있습니다.

포털로 로그온하여 새로 만들기 > 데이터 + 저장소 > SQL Data Warehouse를 클릭합니다.

이름을 입력합니다. 성능의 경우는 400 DTU 부터 시작하는 것이 좋다고 언급하고 있으며 필요시 슬라이더를 움직여서 몇 초 안에 적용이 가능합니다.

서버의 경우 V12 로 서버를 만들거나 기존 서버를 선택하면 됩니다. 소스 선택에서는 빈 데이터베이스, 샘플 또는 백업에서 생성을 할 수 있습니다.

생성이 완료되었다면 서버에서 방화벽설정을 하게 됩니다. Azure SQL Database와 동일한 방식입니다. DW 이므로 사용하지 않는 경우 데이터베이스 설정의 크기 조정에서 슬라이더를 왼쪽으로 이동하여 비용을 줄이고 필요하다면 일시 정지 시킬 수도 있습니다.

이제 SQL Server Management Studio, Visual Studio, SSIS, Power BI 등에서 SQL 데이터 웨어하우스를 연결할 수 있습니다.

 

신고
posted by 정홍주
2016.02.12 08:30 Microsft Azure/SQL Databases

Azure SQL Database – 감사(Audit)와 위협 검색(Threat Detection)

 

로컬 SQL 데이터베이스에 대해서는 Audit 개체를 제공해주고 있어 필요하다면 감사 정책을 통해 쿼리, 인증 등을 감사할 수 있습니다.

Azure SQL 데이터베이스에도 감사가 가능하며 해당 데이터베이스 속성으로 이동하여 보안 영역 중 감사 및 위협 검색 부분에서 설정할 수 있습니다.

설정시 저장소에 기록이 되며 Excel 감사 템플릿이나 저장소 탐색기 등을 통해서 확인이 가능합니다. 서버 감사 설정으로 전체 데이터베이스에 상속을 시켜주거나 상속을 재정의할 수도 있습니다.

감사에 대한 이벤트 범주는 일반 SQL 부터, 로그인까지 가능하며 데이터베이스 성능을 고려하여 설정해야 합니다.

아래 그림은 Excel 감사 템플릿 결과 화면이며 Demo 계정이 저장 프로시저를 실행한 내용입니다.

 

위협 검색은 Threat Detection으로 위협 탐지라고 일반적으로 얘기하는 것인데 위협 검색으로 번역되어 나타납니다. 위협 검색은 감사를 설정해야 설정할 수 있습니다. 감사 데이터 중에서 위협에 해당할 경우 전자메일로 전송해주게 됩니다.

위협 검색 유형을 보면 SQL Injection 공격에 대한 부분과 새로운 위치에서 로그인이 포함되어 있어 위협을 탐지 할 수 있습니다. 하지만 완벽한 보안 솔루션은 아닙니다.

 

 

신고
posted by 정홍주
2015.11.27 08:00 Microsft Azure/SQL Databases

 

Azure SQL Database Always Encryption

 

Always Encryption 은 항상 암호화로 번역되어 나오는데 클라이언트부터 암호화되어 추가되며 복호화되어 클라이언트에 나타나는 SQL Server 2016의 기능인데 Azure SQL Database까지 지원하고 있습니다. 클라이언트로부터 암호화된다는 것이 글로 설명하기는 제한적이며 아래 링크를 참고할 수 있습니다. 아래 링크에서 그림을 보면 쉽게 이해가 가능합니다.

https://msdn.microsoft.com/en-us/library/mt163865(v=sql.130).aspx

Azure SQL Database 에 항상 암호화를 적용해보도록 하겠습니다.  아래 주소 내용과 유사하게 진행해보겠습니다.

http://blogs.msdn.com/b/sqlsecurity/archive/2015/11/01/ssms-encryption-wizard-enabling-always-encrypted-made-easy.aspx

 

데이터베이스를 Azure SQL Database 에 생성하고 테이블을 아래와 같이 생성합니다. 이 중에서 SSN, Birthdate 는 민감정보로 암호화를 해야 할 경우 여러 방법이 있겠지만 항상 암호화 기능을 사용할 수 있습니다.

SQL Server 2016SSMS에서 Azure SQL Database를 연결하고 데이터베이스를 오른쪽 클릭하거나 해당 암호화할 테이블을 오른쪽 클릭하여 열 암호화를 선택합니다. 테스트를 위해서는 미리 데이터를 삽입해 두는 것이 편합니다.

암호화 마법사 그림을 보면 좀 더 쉽게 이해가 가능합니다.

테이블에서 해당 암호화 열을 선택할 수 있습니다.

열을 선택하면 암호화 유형을 선택해야 하는데 결정적, 임의 암호화 유형이 있으며 장단점이 있으므로 적절한 유형을 선택할 수 있습니다.

아래 그림에서 암호화 유형에 대한 내용을 정리하고 있습니다. 위 테이블의 SSN 같은 경우 필터링, 조인 등을 사용하므로 결정적 암호화로 항상 같은 암호화 값을 제공하여 인덱싱도 가능합니다. 하지만 데이터를 유추할 가능성이 높습니다.

암호화에 사용되는 마스터 키를 구성할 수 있습니다. 인증서 저장소와 Azure Key Vault 에 저장 가능합니다.

PowerShell 스크립트를 통해 암호화를 다른 서버에도 적용할 있습니다.

최종적으로 확인하고 다음을 클릭하면 암호화를 진행하면서 암호화 열 스키마를 변경하게 됩니다.

작업이 다 완료되었습니다.

테이블을 스크립팅해보면 아래와 같은 암호화 열 스키마를 확인할 수 있습니다. AES256, CBC 모드인 것을 확인 할 수 있습니다.

새 쿼리 창을 통해 Azure SQL Database를 연결하여 테이블을 쿼리하면 암호화 된 내용을 바로 확인할 수 있습니다.

 

클라이언트에서 복호화되게 하려면 마스터 키 연결에 따라 달라지지만 연결 문자열 매개변수를 추가하여 연결하면 됩니다.

column encryption setting=enabled

테이블을 쿼리하면 복호화 된 내용을 바로 확인할 수 있습니다.

 

응용프로그램 코드를 통해서 확인해보겠습니다. 마찬가지로 연결 문자열에 열 암호화 설정이 추가되어 있습니다. 직접 INSERT 구문을 적용할 경우 제한적이며 @매개변수 또는 저장 프로시저의 매개변수를 통해 진행해야 합니다.

응용프로그램을 실행하면 아래와 같은 구문이 클라이언트(ADO.NET)로부터 생성되어 서버로 전달됩니다. 반대로 클라이언트(ADO.NET)에서 복호화되게 됩니다.

클라이언트 코드에 대한 내용은 아래 링크를 참고할 수 있습니다.

https://msdn.microsoft.com/en-us/library/mt147923.aspx

 

이상으로 항상 암호화를 살펴보았습니다. 항상 암호화는 열 암호화 대상에 제한이 있으며 SQL Server 2016 SSMSADO.NET-.NET Framework 4.6 이상을 통해서 가능한 측면이 있으며 마스터 키 위치에 따라 달라지므로 키 저장소도 사전에 고려해야 합니다.

 

항상 암호화를 통해 중요한 정보를 암호화 할 수 있는데 클라이언트는 항상 암호화를 통해서 응용 프로그램 내부에서 데이터를 암호화 할 수 있으며 SQL Server에는 암호화 키가 노출되지 않고 Azure SQL Database까지 지원하여 장점을 제공하고 있습니다.

 

신고
posted by 정홍주
2015.10.23 08:00 Microsft Azure/SQL Databases

 

Azure Active Directory (Azure AD) 인증

 

Azure SQL Database 에서 Azure Active Directory (Azure AD) 인증에 대한 부분을 알아보겠습니다. 현재는 제한적인 측면이 있으니 아래 링크를 먼저 확인해야 합니다.

https://azure.microsoft.com/en-us/documentation/articles/sql-database-aad-authentication/?wt.mc_id=WW_CE_DM_OO_BLOG_NONE

 

Azure SQL Database 를 연결할 수 있는 도구는 현재 SQL Server 2016 SSMS, Visual Studio 2015 SSDT 이며 연결 문자열에서  .NET Framework Data Provider for SqlServer (at least version .NET Framework 4.6)으로 연결 가능합니다.

Azure SQL Server를 위한 Azure AD 관리자는 한 명만 생성할 수 있습니다.

 

먼저 Azure AD 도메인 생성, Azure SQL Database v12 생성합니다. Azure SQL Server를 위한 Azure AD 관리자 설정은 아래 절차대로 수행합니다.

1.     미리 보기 포탈에 로그온하여 SQL Server를 클릭하고 설정을 클릭합니다.

2.     미리 보기를 수락합니다.

3.     상단 메뉴에서 관리자 설정 메뉴를 클릭합니다.

4.     관리자 추가화면에서 SQL Server 사용자를 선택합니다.

5.     저장을 클릭합니다.

 

이제 SSMS등으로 연결하여 포함된 데이터베이스에 AD 사용자나 그룹을 생성할 수 있습니다.

CREATE USER [xxx@xxx.onmicrosoft.com] FROM EXTERNAL PROVIDER;

 

연결 문자열로는 아래처럼 Azure AD를 통해 연결하게 할 수 있습니다.

 

string ConnectionString =

@"Data Source=xxx.database.windows.net; Authentication=Active Directory Integrated;";

SqlConnection conn = new SqlConnection(ConnectionString);

 

string ConnectionString =

@"Data Source=xxx.database.windows.net; Authentication=Active Directory Password;

UID=xxx@xxx.onmicrosoft.com; PWD=xxx";

SqlConnection conn = new SqlConnection(ConnectionString);

 

간략히 Azure SQL ServerAzure AD 인증에 대한 내용을 살펴보았습니다.

신고
posted by 정홍주
2015.10.23 08:00 Microsft Azure/SQL Databases

 

Azure SQL Database Security

 

Azure SQL Database 에서 1014일에 발표된 보안 강화에 대한 내용을 정리해보겠습니다.

아래 링크를 확인해보면 SQL Server Azure SQL Database는 다른 DBMS보다는 취약점이 제일 적게 나타났습니다.

https://azure.microsoft.com/ko-kr/blog/microsoft-azure-sql-database-provides-unparalleled-data-security-in-the-cloud-with-always-encrypted/

 

 

위 링크에 소개된 Azure SQL Database 보안 내용과 보안에 대한 10월 업데이트 내용입니다.

l  Always Encrypted

https://msdn.microsoft.com/en-us/library/mt163865.aspx?wt.mc_id=WW_CE_DM_OO_BLOG_NONE

l  Transparent Data Encryption

https://msdn.microsoft.com/library/dn948096.aspx?wt.mc_id=WW_CE_DM_OO_BLOG_NONE

l  Azure Active Directory (Azure AD) 인증

https://azure.microsoft.com/en-us/documentation/articles/sql-database-aad-authentication/?wt.mc_id=WW_CE_DM_OO_BLOG_NONE

l  Row-Level Security(행 수준 잠금)

https://msdn.microsoft.com/library/dn765131?wt.mc_id=WW_CE_DM_OO_BLOG_NONE

l  동적 데이터 마스킹(Dynamic Data Masking)

https://azure.microsoft.com/en-us/documentation/articles/sql-database-dynamic-data-masking-get-started/?wt.mc_id=WW_CE_DM_OO_BLOG_NONE

l  Azure SQL Database 감사

https://azure.microsoft.com/en-us/documentation/articles/sql-database-auditing-get-started/?wt.mc_id=WW_CE_DM_OO_BLOG_NONE

 

 

위 내용 중에서 대부분 블로그에 올라가 있으며 Azure Active Directory (Azure AD) 인증, Always Encrypted 내용을 다루어보겠습니다.

 

 

신고
posted by 정홍주
2015.07.10 08:00 Microsft Azure/SQL Databases

SQL Database V12 – 투명한 데이터 암호화(Transparent Data Encryption)

 

이번 글에서는 Azure SQL Database V12에서 투명한 데이터 암호화(TDE)를 지원하는 내용을 살펴보겠습니다. 보다 더 자세한 정보는 아래 링크를 참고할 수 있습니다.

https://msdn.microsoft.com/library/0bf7e8ff-1416-4923-9c4c-49341e208c62.aspx

 

Azure SQL Database V12의 새로운 기능에 대한 내용은 아래 링크를 참고할 수 있습니다.

https://azure.microsoft.com/ko-kr/documentation/articles/sql-database-v12-whats-new/

 

투명한 데이터 암호화(TDE) 설정하는 방법은 여러 가지 방법이 있습니다.

l  미리보기 포털

l  T-SQL 구문

l  PowerShell 스크립트

 

투명한 데이터 암호화(TDE) 설정은 미리보기 포털을 통해서 액세스 해보겠습니다.

1.     https://portal.azure.com 로 이동하여 V12 데이터베이스로 이동합니다.

2.     해당 데이터베이스 메뉴에서 모든 설정 메뉴를 클릭하면 투명한 데이터 암호화 메뉴를 볼 수 있습니다.
 

3.     미리 보기 조건을 수락해야 사용할 수 있습니다. 미리 보기 조건을 클릭하고 체크하고 확인을 클릭합니다.
   

4.     데이터 암호화 설정 메뉴를 선택하고 저장을 클릭하면 됩니다.   

5.     암호화 진행 메뉴를 살펴볼 수 있습니다.   

6.     암호화가 완료되면 아래 그림처럼 암호화됨상태를 확인할 수 있습니다.   

7.     T-SQL로 암호화 상태를 확인할 수 있습니다. sys.dm_database_encryption_keys 뷰의 encryption_state 값을 통해서 확인이 가능합니다. 뷰의 자세한 정보는 아래 링크를 참고할 수 있습니다.

SELECT * FROM  sys.dm_database_encryption_keys

 

https://msdn.microsoft.com/ko-kr/library/bb677274.aspx

  

 

암호화 되어 있는 데이터베이스의 경우 포털 이미지에 열쇠 표시로 나타납니다.

추가로 T-SQL 구문으로는 아래와 같은 구문으로 투명한 데이터 암호화(TDE) 설정이 가능합니다.

 

-- database encryption key 생성

CREATE DATABASE ENCRYPTION KEY

WITH ALGORITHM = AES_256

ENCRYPTION BY SERVER CERTIFICATE ##MS_TdeCertificate##;

 

-- 암호화 설정

ALTER DATABASE [AdventureWorksLT] SET ENCRYPTION ON;

GO

 

 

투명한 데이터 암호화(TDE) 설정은 지리적 복제, 특정 시점 복원, 삭제된 데이터베이스로부터 복원, 데이터베이스 복사 등에서도 설정이 상속되어 복호화 등의 설정은 필요 없습니다.

그래서 간단하게 다른 서버로 데이터베이스를 복사하여 설정을 확인해보았습니다. 

 

그러나 Bac 로 내보내기하여 다시 가져오기할 경우는 암호화되어 내보내는 것은 아니라고 설명이 되어 있어 테스트를 해보았습니다. 암호화되어 있지 않은 것으로 나타납니다.

 

Bac 파일 같은 경우 로컬로 복사할 수도 있어 다른 서버에 복원할 경우 복원이 된다는 것이 생각과는 다르며 Azure TDE 미리보기와 로컬 TDE와 차이가 있습니다. 이점은 고려해야 할 사항입니다.

 

신고
posted by 정홍주
TAG TDE, 정홍주
2015.07.08 08:00 Microsft Azure/SQL Databases

 

SQL Database V12 – 행 수준 보안(Row-Level Security)

 

이번 글에서는 Azure SQL Database V12에서의 행 수준 보안(Row-Level Security)에 대한 내용을 살펴보려 합니다. 행 수준 보안(RLS)의 경우 SQL Server 2014에서 지원되는 기능으로 사용자별로 SELECT 결과값이 다르게 나오게 하는 것으로 사전 설정된 행 필터에 따라 결과를 표시하므로 사용자마다 다른 결과값을 보게 됩니다.

 

Azure SQL Database V12의 새로운 기능에 대한 내용은 아래 링크를 참고할 수 있습니다.

https://azure.microsoft.com/ko-kr/documentation/articles/sql-database-v12-whats-new/

 

행 수준 보안(RLS)에 대한 내용은 아래 링크를 참고할 수 있습니다. 행 수준 보안을 적용하게 하려면 먼저 사용자별로 연결이 설정되어야 합니다. 일반적인 단일 사용자로만 들어오게 되면 행 수준 보안은 의미가 없으며 여러 사용자별로 실행된다면 행 수준의 액세스를 제어할 수 있습니다.

https://msdn.microsoft.com/library/dn765131.aspx

 

위 링크의 예제를 활용하여 Azure SQL Database V12에서 행 수준 보안을 아래와 같이 적용해보았습니다. 위 링크의 경우 행 수준별 사용자를 한명만 할당하게 되는데 이는 여러 명이 해당 행을 접근할 수 있는 경우라면 비효율적이라 역할 기반으로 수정해서 적용해보았습니다.

 

 

-- 사용자를 생성합니다, Sales Region 별 사용자를 생성해서

-- 지역별 행 수준 보안을 적용해보겠습니다.

CREATE USER Manager WITHOUT LOGIN;

CREATE USER SalesUS WITHOUT LOGIN;

CREATE USER SalesEU WITHOUT LOGIN;

CREATE USER SalesKR WITHOUT LOGIN;

GO

 

-- 한 행당 사용자 한명으로 할당하지 않고 역할 기반을 구성하기 위한

-- 사용자 테이블을 생성합니다.

CREATE TABLE SalesRep

(ID INT IDENTITY PRIMARY KEY,

UserName sysname

)

GO

-- 사용자 여러 명을 하나의 역할로 묶어주는 역할 테이블을 생성합니다.

CREATE TABLE RLSRole

(ID INT IDENTITY PRIMARY KEY

, RoleName sysname

, SalesRepID INT REFERENCES SalesRep(ID)

)

GO

 

INSERT SalesRep VALUES(N'Manager')

INSERT SalesRep VALUES(N'SalesUS')

INSERT SalesRep VALUES(N'SalesEU')

INSERT SalesRep VALUES(N'SalesKR')

 

GO

INSERT RLSRole VALUES(N'ManagerGroup',1)

INSERT RLSRole VALUES(N'USGroup',2)

INSERT RLSRole VALUES(N'EUGroup',3)

INSERT RLSRole VALUES(N'KRGroup',4)

 

-- 최종 결과에서 다시 INSERT 해서 결과를 확인할 구문입니다.

--  INSERT RLSRole VALUES(N'EUGroup',4)

 

GO

 

-- 실제 데이터 값을 가지고 있는 테이블을 생성합니다.

-- RoleName 이라는 열을 행 수준 보안에서 사용할 것입니다.

CREATE TABLE Sales

    (

    OrderID int,

    RoleName sysname,

    Product varchar(10),

    Qty int

    );

 

GO

INSERT Sales VALUES

(1, 'USGroup', 'Valve', 5),

(2, 'USGroup', 'Wheel', 2),

(3, 'EUGroup', 'Valve', 4),

(4, 'EUGroup', 'Bracket', 2),

(5, 'KRGroup', 'Wheel', 5),

(6, 'KRGroup', 'Seat', 5);

 

SELECT * FROM Sales;

 

-- 테이블에 SELCT 권한을 부여합니다.

GRANT SELECT ON Sales TO Manager;

GRANT SELECT ON Sales TO SalesUS;

GRANT SELECT ON Sales TO SalesEU;

GRANT SELECT ON Sales TO SalesKR;

 

 

CREATE SCHEMA Security;

GO

-- 사용자 함수를 생성합니다. 매개변수는 역할 이름이며

-- 역할테이블과 사용자테이블을 조인하여 현재 사용자 정보로 필터링하는 함수입니다.

-- Manager 일 경우 전체가 반환되도록 되어 있으며

-- 비지니스 로직을 적용하여 행 수준 보안을 구성하기 위한 함수 입니다.

CREATE FUNCTION Security.fn_securitypredicate

(@RoleName AS sysname)

    RETURNS TABLE

WITH SCHEMABINDING

AS

    RETURN SELECT 1 AS fn_securitypredicate_result

             FROM dbo.RLSRole AS r INNER JOIN dbo.SalesRep AS s

             ON r.SalesRepID =s.ID

WHERE (@RoleName =r.RoleName AND s.UserName= USER_NAME() )

                           OR ( USER_NAME() = 'Manager');

 

 

 

-- 행 수준 보안의 핵심이며 ADD FILTER PREDICATE 정책을 Sales 테이블에 적용하는 구문입니다.

-- 행 필터는 위에서 생성한 함수이며 Sales 테이블의 역할 이름을 매개변수로 전달합니다.

CREATE SECURITY POLICY SalesFilter

ADD FILTER PREDICATE Security.fn_securitypredicate(RoleName)

ON dbo.Sales

WITH (STATE = ON);

 

-- EXECUTE AS 구문을 통해서 테스트합니다.

EXECUTE AS USER = 'SalesUS';

SELECT * FROM Sales;

REVERT;

 

/*

1            USGroup             Valve     5

2            USGroup             Wheel    2

*/

 

EXECUTE AS USER = 'SalesEU';

SELECT * FROM Sales;

REVERT;

/*

3            EUGroup             Valve     4

4            EUGroup             Bracket  2

*/

 

EXECUTE AS USER = 'SalesKR';

SELECT * FROM Sales;

REVERT;

/*

5            KRGroup             Wheel    5

6            KRGroup             Seat       5

*/

 

 

EXECUTE AS USER = 'Manager';

SELECT * FROM Sales;

REVERT;

/*

1            USGroup             Valve     5

2            USGroup             Wheel    2

3            EUGroup             Valve     4

4            EUGroup             Bracket  2

5            KRGroup             Wheel    5

6            KRGroup             Seat       5

*/

 

 

 

 

--  INSERT RLSRole VALUES(N'EUGroup',4)

-- 구문을 실행하여 SalesKR 사용자는 EUGroup 역할에도 포함하게 합니다.

-- EUGroup 역할에 속하기 때문에 실행 결과는 유럽 지역까지 결과에 나타납니다.

 

EXECUTE AS USER = 'SalesKR';

SELECT * FROM Sales;

REVERT;

/*

3            EUGroup             Valve     4

4            EUGroup             Bracket  2

5            KRGroup             Wheel    5

6            KRGroup             Seat       5

*/

 

 

-- 아래는 수준 보안을 해제합니다.

-- 테이블이나 함수의 스키마를 변경하려면 해제해야 합니다.

ALTER SECURITY POLICY SalesFilter

WITH (STATE = OFF);

 

 

행 수준 보안을 적용하게 하려면 먼저 사용자별로 연결이 설정되어야 합니다. 또한 사용자 함수를 기반으로 하기 때문에 데이터 건수가 많은 테이블의 경우 성능에 대한 테스트도 필요할 것으로 보입니다.

이번 글을 통해 Azure SQL Database V12에서도 RLS 를 지원한다는 것을 간략히 살펴보았습니다.

 

 

신고
posted by 정홍주
TAG RLS, 정홍주
2015.07.03 08:00 Microsft Azure/SQL Databases

SQL Database V12 – DataMasking

 

이번 글에서는 Azure SQL Database V12에서의 동적 데이터 마스킹에 대한 내용을 살펴보려 합니다. 데이터 마스킹은 이벤트 당첨 페이지 등에서 많이 보는 것으로 홍*, 01-****-5678 이런 식으로 표시하는 것을 말합니다.

 

먼저 개인정보의 기술적 관리적 보호조치 기준 해설서를 보면 아래와 같이 조항이 있습니다.

해당 예시 화면은 아래와 같이 나타납니다.

성명

*

생년월일

******

전화번호

02-****-1234

핸드폰

010-****-1234

주소

서울 종로구 ****12-3

접속지 IP

123.123.***.123

 

데이터베이스에는 제대로 들어가 있는 값을 콜센터등 응용프로그램에서 표시할 경우 화면에 표시하기 전에 위와 같이 나타나게 해주어야 합니다. 그리고 데이터베이스를 사용하는 데이터베이스 도구에서도 쿼리를 조회할 경우 위와 같이 결과를 나타나게 해야 하는 것도 필요할 것 같습니다.

 

Azure SQL Database V12 에서는 간단하게 데이터 마스킹을 처리해줄 수 있습니다. 몇몇 제공하는 템플릿과 커스텀 지정을 통해 개인 정보에 대한 표시제한을 진행할 수 있습니다.

 

1.     먼저 V12 데이터베이스를 생성하고 사용자/로그인, 테이블을 생성해야 합니다.

2.     해당 데이터베이스의 감사 및 보안 메뉴로 이동합니다. 동적 데이터 마스킹 메뉴를 볼 수 있습니다.

3.     감사 및 보안에서 동적 데이터 마스킹을 설정합니다.

 

4.     권한 있는 로그인은 조회할 때 값이 다 보이게 하는 로그인이 있다면 추가할 수 있습니다.

5.     하단의 마스크 추가 메뉴를 클릭하여 마스크를 추가할 수 있습니다.

6.     마스크 추가 메뉴에서는 테이블, 컬럼, 마스킹 기능을 추가할 수 있습니다. 주민등록번호, 이메일등에 대한 템플릿과 기본값, 사용자 지정을 통해 구성이 가능합니다.

7.     아래 구문은 마스킹을 할 테이블입니다.

CREATE TABLE DataMasking

(

ID INT PRIMARY KEY,

DefaultValue1 INT,

DefaultValue2 NVARCHAR(50),

DefaultValue3 DATETIME,

CardNo NVARCHAR(50),

SSN NVARCHAR(50),

Email NVARCHAR(50),

Num INT,

CustomStr NVARCHAR(50),

Name NVARCHAR(50),

TelNo NVARCHAR(50)

)

GO

 

 

값은 아래의 예와 유사한 값을 입력했습니다.

 

INSERT DataMasking

VALUES (1, 1234,N'기본값',N'2015-06-29'

, N'1234-4567-7890-1234',N'111111-1111111',N'test@test.com',N'1234',N'커스텀텍스트',N'홍길동', N'010-1234-5678')

 

 

8.     마스킹을 아래와 같이 설정하였습니다.

9.     SSMS를 통해 일반 사용자로 연결하여 데이터를 조회해보겠습니다.

10.   사용자 지정의 예로 TelNo 같은 경우는 아래 그림처럼 접두가와 접미사를 4로 지정하고 중간은 ****로 처리했습니다. 접미사를 5로 지정해야 까지 나옵니다.  
  

11.   다음은 응용프로그램에서 값을 조회해보겠습니다.

 

V12에서 개인정보의 표시 제한에 대한 내용으로 데이터 마스킹을 알아보았습니다.

 

 

신고
posted by 정홍주
2015.07.01 08:00 Microsft Azure/SQL Databases

SQL Database V12 – SQL CLR

 

SQL Server 에서 지원되는 SQL CLR AzureSQL Database V12 에서도 지원합니다. SQL CLR을 많이 사용하지 않을 수 도 있지만 SQL Server 2014의 프로그래밍 관련 내용이 SQL Database V12에서도 지원되는 것을 확인할 수 있습니다.

SQL Database V12의 새로운 내용에 대한 사항은 아래 링크를 참고할 수 있습니다.

https://azure.microsoft.com/en-us/documentation/articles/sql-database-v12-whats-new/

 

SQL CLR을 생성하기 위해서 Visual Studio에서 프로젝트를 생성할 수 있습니다. Visual Studio에는 최신 SSDT(SQL Server Database Tools)가 설치되어 있어야 합니다.

https://msdn.microsoft.com/en-us/dn864412

 

1.     SQL Server 프로젝트를 생성합니다.

 

2.     프로젝트를 생성하고 나면 프로젝트 설정으로 이동하여 대상 플랫폼을 Azure SQL Database V12로 지정합니다. Azure SQL Database V12가 나오지 않는다면 SSDT 최신 버전이 설치되지 않을 것입니다. 빌드해도 오류가 발생합니다. (SQLBuildTask)

 

3.     SQL CLR에 대한 항목을 추가하여 코드를 작성합니다. 아래는 해당 서버 버전을 반환하는 SQL CLR 저장 프로시저 내용입니다.

     [Microsoft.SqlServer.Server.SqlProcedure]

    public static void SendReaderToClient()

    {

        using (SqlConnection connection = new SqlConnection("context connection=true"))

        {

            connection.Open();

            SqlCommand command = new SqlCommand("select @@version", connection);

            SqlDataReader r = command.ExecuteReader();

            SqlContext.Pipe.Send(r);

        }

    }

 

 

4.      코딩 작업을 완료했다면 스크립트를 생성하여 T-SQL 구문을 실행할 수 있습니다. 프로젝트를 오른쪽 클릭하여 게시를 선택합니다. 게시 창에서는 Azure SQL Database V12를 연결하여 설정해줍니다.

5.      아래와 같이 게시 SQL 스크립트를 확인할 수 있습니다.


6.      Azure Database V12에 연결하여 스크립트를 실행하여 어셈블리를 생성하고 SQL CLR 저장 프로시저를 생성할 수 있습니다. 시스템 뷰를 통해 어셈블리를 확인할 수 있습니다.

7.      SQL CLR 저장 프로시저를 호출하여 결과를 확인해볼 수 있습니다.

EXEC [dbo].[SendReaderToClient]

--Microsoft SQL Azure (RTM) - 12.0.2000.8 Jun 12 2015 15:07:27 Copyright (c) Microsoft Corporation

 

 

 

이상으로 간단히 Azure SQL Database V12에서 SQL CLR 지원을 확인해보았습니다.

 

신고
posted by 정홍주
2015.04.23 08:45 Microsft Azure/SQL Databases

 

SQL Database V12 – T-SQL 지원 강화

 

SQL Database V12T-SQL 지원 강화에 대한 내용을 알아보겠습니다. 사실 V11에서 일반적인 OLTP에서 사용하는 대부분의 T-SQL(OffSet 페이징 쿼리 등)은 지원을 하고 있었으며 V12에서 T-SQL 지원의 변경사항은 크지 않은 것 같습니다.

SQL Database V12에 대한 내용은 아래 링크를 참고하십시오.

http://azure.microsoft.com/en-us/documentation/articles/sql-database-preview-whats-new/

 

ALTER TABLE 구문 일부, 분할된 테이블, XML 인덱스, 온라인 인덱스, SQL CLR 지원 등에 대한 내용이 변경되었습니다. 간단히 아래에서 Heap 지원, Windows 함수에 대한 내용을 다루어 보겠습니다.

l  Heap

Heap(클러스터 인덱스가 없는 테이블)의 경우 V12에서는 생성이 가능합니다. 복제 등에 참여하고 있는 경우 제한될 수 있습니다. 아래 구문을 V11에서 실행하면 오류가 발생합니다.

 

CREATE TABLE Heap

(ID INT

,Name NVARCHAR(30) )

GO

INSERT Heap VALUES (1, N'Name')

 

Tables without a clustered index are not supported in this version of SQL Server. Please create a clustered index and try again.

 

V12에서는 INSERT가 잘되는 것을 확인할 수 있습니다. 

 

l  Windows 함수

자주 쓰는 OffSet, OVER 절에 대한 내용은 V11에서도 잘 사용했었습니다. 특히 페이징 쿼리는 유용하게 사용했었습니다. V12에서 LEAD, LAG 등의 함수가 지원된다는 것이 T-SQL 지원 강화에서의 내용입니다.

아래 LEAD 구문을 V11에서 실행하면 오류가 발생합니다.

SELECT BusinessEntityID

, YEAR(QuotaDate) AS SalesYear

, SalesQuota AS CurrentQuota,

    LEAD(SalesQuota, 1,0) OVER (ORDER BY YEAR(QuotaDate)) AS NextQuota

FROM Sales.SalesPersonQuotaHistory

WHERE BusinessEntityID = 275

and YEAR(QuotaDate) IN ('2005','2006');

 

Keyword or statement option 'lead' is not supported in this version of SQL Server.

 

V12에서는 잘 실행되는 것을 알 수 있습니다. 


T-SQL 지원 강화에서는 OLTP의 대부분의 쿼리를 V11에서 지원하고 있었으며 일부 강화된 내용을 V12에서 확인 가능합니다.

 

신고
posted by 정홍주