6 Lớp Mã Hoá Bảo Vệ Dữ Liệu Windows Server 2022

Ổ cứng máy chủ của công ty bạn đang nằm ở đâu ngay lúc này — trong phòng server có khoá, hay đang ngồi trên giá đỡ của một trung tâm dữ liệu thuê ngoài mà chưa ai trong công ty từng bước chân vào kiểm tra? Nếu một ngày ổ cứng đó bị tháo ra — do trộm cắp, do nhân viên kỹ thuật của bên thuê hạ tầng làm sai quy trình, hay đơn giản là thanh lý thiết bị cũ mà quên xoá — người cầm ổ cứng đó có đọc được dữ liệu khách hàng của bạn không?

Với rất nhiều máy chủ Windows Server đang chạy ở Việt Nam, câu trả lời là có — vì ổ đĩa chưa từng được mã hoá. Toàn bộ dữ liệu nằm ở dạng đọc được ngay, chỉ cần cắm ổ vào một máy khác.

Đây không phải chuyện xa vời. Đó là lý do bài này tồn tại: đi qua từng lớp mã hoá mà Windows Server 2022 có sẵn — từ ổ đĩa, đường truyền, tới cơ sở dữ liệu — để bạn (chủ doanh nghiệp) hiểu vì sao nó quan trọng, và để IT Admin của bạn có đủ lệnh cụ thể để bật lên, đúng thứ tự, không bỏ sót.

Phần 1 — Dành cho chủ doanh nghiệp và người quản lý

(Không cần biết kỹ thuật vẫn đọc hiểu trọn phần này. Muốn làm được việc thật, chuyển IT Admin sang Phần 2.)

Vì sao "mã hoá dữ liệu" không phải chuyện của riêng IT

Mã hoá (encryption) là biến dữ liệu thành một chuỗi vô nghĩa nếu không có đúng khoá giải mã. Nó không ngăn được việc ai đó lấy trộm ổ cứng, đọc trộm gói tin trên đường truyền, hay copy database — nhưng nó khiến thứ lấy được vô dụng nếu không có khoá. Với một doanh nghiệp đang lưu dữ liệu khách hàng (tên, số điện thoại, địa chỉ, lịch sử giao dịch, thậm chí thông tin thanh toán) trên máy chủ Windows Server, bốn rủi ro cụ thể sau đây là lý do mã hoá không còn là "nên có" mà là "phải có":

1. Mất thiết bị vật lý, mất luôn dữ liệu. Máy chủ bị trộm, ổ cứng hỏng phải gửi bảo hành, thiết bị thanh lý không xoá sạch — nếu ổ đĩa không được mã hoá, người cầm nó đọc được mọi thứ. Nếu có mã hoá (BitLocker), ổ đĩa tháo ra chỉ là một cục sắt vô dụng nếu không có khoá phục hồi.

2. Dữ liệu bị nghe lén khi truyền qua mạng. Mỗi lần nhân viên truy cập hệ thống từ xa, mỗi lần website gọi tới database, mỗi lần file được chia sẻ qua mạng nội bộ — nếu đường truyền không mã hoá, ai đó chặn được gói tin trên đường đi là đọc được nguyên văn. Đây là lớp TLS và SMB Encryption sẽ nói ở dưới.

3. Rủi ro pháp lý theo luật Việt Nam. Nghị định 13/2023/NĐ-CP mà nhiều bài viết còn nhắc tới đã không còn là khung áp dụng. Từ 01/01/2026, Luật Bảo vệ dữ liệu cá nhân số 91/2025/QH15 cùng Nghị định hướng dẫn 356/2025/NĐ-CP mới là văn bản điều chỉnh; và từ 19/8/2026, chế tài cụ thể nằm ở Nghị định 330/2026/NĐ-CP. Doanh nghiệp không triển khai biện pháp bảo vệ dữ liệu cá nhân phù hợp, dẫn tới lộ hoặc mất dữ liệu đã thu thập bị phạt 20–30 triệu đồng (mức dành cho tổ chức; cá nhân bằng một nửa), kèm việc buộc phải triển khai biện pháp bảo vệ và đánh giá rủi ro, nộp minh chứng cho cơ quan chức năng.

Con số đó nghe nhẹ, nhưng nó chỉ là một dòng trong hoá đơn. Một vụ lộ dữ liệu thật gần như luôn kích hoạt nhiều lỗi cùng lúc: báo cho cơ quan chuyên trách chậm quá 72 giờ (40–60 triệu); chưa có hồ sơ đánh giá tác động xử lý dữ liệu cá nhân (20–30 triệu, kèm buộc dừng toàn bộ hoạt động xử lý dữ liệu cá nhân cho tới khi nộp hồ sơ và được xác nhận — với phần lớn doanh nghiệp, đây mới là thiệt hại thật sự); chuyển giao dữ liệu nhạy cảm mà không mã hoá (50–80 triệu). Riêng với điện toán đám mây, nghị định ghi thẳng: bên cung cấp hoặc bên sử dụng dịch vụ mà không mã hoá dữ liệu cá nhân của khách hàng ở trạng thái lưu trữ và trong quá trình truyền tải thì bị phạt 50–70 triệu đồng. Trần phạt chung cho các vi phạm khác về dữ liệu cá nhân là 3 tỷ đồng với tổ chức. Ngoài phạt hành chính, doanh nghiệp còn có thể phải bồi thường thiệt hại và tuỳ mức độ bị truy cứu trách nhiệm hình sự.

Cần nói thẳng một điểm rất hay bị hiểu nhầm: mã hoá không đồng nghĩa với tuân thủ. Luật 91/2025 để doanh nghiệp tự quyết định mã hoá thế nào cho phù hợp với hoạt động xử lý dữ liệu của mình — nghĩa là bật BitLocker xong không phải là "xong luật". Luật đòi biện pháp quản lý và kỹ thuật phù hợp, được rà soát cập nhật khi cần, cộng với các nghĩa vụ mà mã hoá không thay thế được: xin sự đồng ý đúng cách (rõ ràng, theo từng mục đích, im lặng không được coi là đồng ý), bảo đảm quyền của chủ thể dữ liệu, lập hồ sơ đánh giá tác động xử lý dữ liệu cá nhân và gửi cơ quan chuyên trách trong 60 ngày kể từ ngày đầu tiên xử lý dữ liệu, thông báo vi phạm trong 72 giờ. Vai trò của mã hoá là lớp kỹ thuật làm giảm hậu quả khi sự cố đã xảy ra — ổ đĩa bị lấy đi vẫn vô nghĩa với kẻ cầm được nó — chứ không gánh thay phần hồ sơ và quy trình.

Một lưu ý dễ chịu cho doanh nghiệp nhỏ: Luật 91/2025 cho doanh nghiệp nhỏ và doanh nghiệp khởi nghiệp được chọn không thực hiện nghĩa vụ hồ sơ đánh giá tác động trong 5 năm đầu kể từ 01/01/2026, còn hộ kinh doanh và doanh nghiệp siêu nhỏ được miễn hẳn — trừ khi kinh doanh dịch vụ xử lý dữ liệu cá nhân, trực tiếp xử lý dữ liệu cá nhân nhạy cảm, hoặc xử lý dữ liệu của số lượng lớn chủ thể. Nhưng phần bảo vệ dữ liệu và thông báo sự cố thì không ai được miễn — đó chính là phần mã hoá ổ đĩa đóng vai trò.

4. Uy tín thương hiệu — thứ mất rồi khó lấy lại nhất. Một khách hàng SME khi biết đối tác công nghệ của mình để lộ dữ liệu sẽ không quan tâm nguyên nhân kỹ thuật là gì — họ chỉ nhớ "công ty đó từng làm lộ dữ liệu của tôi." Với doanh nghiệp B2B, một sự cố như vậy có thể ảnh hưởng tới hợp đồng đang đàm phán hoặc đang gia hạn.

Windows Server 2022 bảo vệ dữ liệu ở bao nhiêu lớp?

Không phải một lớp mã hoá là đủ — dữ liệu của bạn tồn tại ở nhiều trạng thái khác nhau (nằm im trên ổ đĩa, đang chạy qua mạng, nằm trong database, nằm trong một file cụ thể), và mỗi trạng thái cần một lớp bảo vệ riêng. Bảng dưới đây tóm tắt để bạn hình dung nhanh — không cần hiểu kỹ thuật, chỉ cần biết "lớp nào lo việc gì":

Không cần bật hết cùng lúc và không phải máy chủ nào cũng cần đủ 6 lớp — máy chủ web thuần thì trọng tâm là BitLocker + TLS; máy chủ chạy database khách hàng thì thêm TDE; máy nhiều người dùng chia sẻ thì thêm EFS. Phần 2 dưới đây IT Admin của bạn sẽ biết chính xác cần bật gì, bằng lệnh gì — và mục Checklist cuối Phần 2 gộp lại thành đúng thứ tự nên làm, kèm lệnh copy-paste chạy thẳng.

Hai câu hỏi thường gặp của người không rành kỹ thuật:

• Mã hoá có làm máy chủ chạy chậm đi không? Có ảnh hưởng nhưng không đáng kể trên phần cứng hiện đại — CPU đời mới đều có tập lệnh tăng tốc mã hoá AES phần cứng (AES-NI), nên BitLocker hay TLS 1.3 hầu như không tạo độ trễ cảm nhận được trong vận hành thường ngày. Riêng SMB Encryption có chi phí xử lý cao hơn một chút khi bật toàn server — nên đây là điểm IT Admin cần đo thử trước khi bật diện rộng.
• Có tốn thêm chi phí license không? Không. Toàn bộ 6 lớp mã hoá trong bài này đều là tính năng có sẵn trong Windows Server 2022 (bản Standard/Datacenter), không phải mua thêm phần mềm thứ ba. Riêng TDE/Always Encrypted đòi hỏi SQL Server. Cụ thể: TDE có trong bản Standard từ SQL Server 2019 trở đi; SQL Server 2017 trở xuống phải là Enterprise; bản Express thì không có. Always Encrypted thì có ở mọi edition từ SQL Server 2016 trở lên.

Phần 2 — Hướng dẫn kỹ thuật cho IT Admin

Từ đây trở xuống là phần dành cho người trực tiếp thao tác trên Windows Server 2022. Các lệnh PowerShell/tên tính năng dưới đây đã đối chiếu tài liệu chính thức của Microsoft (nguồn liệt kê cuối bài).

1. BitLocker — mã hoá ổ đĩa

BitLocker mã hoá toàn bộ volume, dùng thuật toán XTS-AES — theo tài liệu chính thức, khi chưa cấu hình policy, BitLocker mặc định dùng XTS-AES 128-bit; với dữ liệu nhạy cảm nên nâng lên XTS-AES 256-bit qua Group Policy hoặc tham số cmdlet.

Cài đặt tính năng (Windows Server không có sẵn như bản Client):

Install-WindowsFeature BitLocker -IncludeAllSubFeature -IncludeManagementTools -Restart

Kiểm tra TPM trước khi bật (khuyến nghị TPM 2.0):

Get-Tpm

Lưu ý quan trọng: TPM 2.0 chỉ hoạt động đúng khi BIOS/UEFI ở chế độ native UEFI, tắt hẳn Legacy/CSM — nếu máy đang chạy Legacy, phải dùng mbr2gpt.exe chuyển đổi trước khi đổi mode, nếu không hệ điều hành sẽ không boot được.

Bật BitLocker cho ổ hệ điều hành — làm trọn 4 lệnh trong CÙNG một phiên, chưa khởi động lại máy:

# 1. Bật BitLocker, gắn khoá vào TPM
Enable-BitLocker -MountPoint "C:" -EncryptionMethod XtsAes256 -TpmProtector

# 2. Tạo khoá phục hồi 48 số — BẮT BUỘC.
#    -TpmProtector KHÔNG tự sinh khoá phục hồi. Thiếu lệnh này thì bước 3 và 4 không có gì để sao lưu.
Add-BitLockerKeyProtector -MountPoint "C:" -RecoveryPasswordProtector

# 3. Lấy đúng ID của khoá phục hồi.
#    KHÔNG dùng KeyProtector[0] — phần tử đầu tiên thường là TPM, không phải khoá phục hồi.
$idKhoaPhucHoi = (Get-BitLockerVolume -MountPoint "C:").KeyProtector |
    Where-Object { $_.KeyProtectorType -eq 'RecoveryPassword' } |
    Select-Object -ExpandProperty KeyProtectorId

# 4. Sao lưu khoá phục hồi vào Active Directory
Backup-BitLockerKeyProtector -MountPoint "C:" -KeyProtectorId $idKhoaPhucHoi

Xác nhận đã có khoá thật — không tin lệnh chạy không báo lỗi là xong:

manage-bde -protectors -get C:

Kết quả phải liệt kê hai protector: một dòng TPM và một dòng Numerical Password kèm dãy 48 chữ số. Nếu chỉ thấy TPM, nghĩa là chưa có khoá phục hồi nào — quay lại lệnh số 2.

In khoá phục hồi ra để cất bản giấy/bản ngoài hệ thống trước khi khởi động lại:

(Get-BitLockerVolume -MountPoint "C:").KeyProtector |
    Where-Object { $_.KeyProtectorType -eq 'RecoveryPassword' } |
    Select-Object KeyProtectorId, RecoveryPassword

Bật cho ổ dữ liệu (data drive) — cách khuyến nghị cho máy chủ:

# Ổ hệ điều hành C: phải được mã hoá trước thì lệnh tự mở khoá bên dưới mới chạy được
Enable-BitLocker -MountPoint "D:" -EncryptionMethod XtsAes256 -RecoveryPasswordProtector
Enable-BitLockerAutoUnlock -MountPoint "D:"

# Sao lưu khoá phục hồi của ổ D: vào AD, y hệt cách làm với ổ C:
$idD = (Get-BitLockerVolume -MountPoint "D:").KeyProtector |
    Where-Object { $_.KeyProtectorType -eq 'RecoveryPassword' } |
    Select-Object -ExpandProperty KeyProtectorId
Backup-BitLockerKeyProtector -MountPoint "D:" -KeyProtectorId $idD

Trên máy không có TPM (một số VPS/máy ảo cũ), BitLocker vẫn dùng được qua startup key lưu trên USB, nhưng mất khả năng kiểm tra toàn vẹn hệ thống lúc khởi động mà TPM cung cấp — không khuyến khích cho máy chủ production.

2. TLS 1.3 — mã hoá dữ liệu truyền tải

Windows Server 2022 là phiên bản Windows Server đầu tiên hỗ trợ TLS 1.3 ở tầng hệ điều hành (Schannel) — các bản trước đó (2019, 2016) không có. Theo bảng cipher suite chính thức của Microsoft, hai bộ mã TLS 1.3 sau đã nằm sẵn trong danh sách ưu tiên mặc định, không cần bật thủ công:

• TLS_AES_256_GCM_SHA384
• TLS_AES_128_GCM_SHA256

Bộ mã TLS_CHACHA20_POLY1305_SHA256 cũng được Schannel hỗ trợ nhưng không bật mặc định — cần thêm thủ công nếu muốn dùng.

Lưu ý thực tế: hỗ trợ ở tầng hệ điều hành không có nghĩa mọi dịch vụ tự động dùng được TLS 1.3 — IIS, SQL Server hay ứng dụng .NET cũ có thể cần cấu hình/bản vá riêng (ví dụ SQL Server 2022 trở lên mới hỗ trợ TLS 1.3 cho kết nối tới database engine). Nên kiểm tra bằng công cụ quét TLS thực tế trước khi enforce bắt buộc TLS 1.3 toàn hệ thống, để tránh chặn nhầm client cũ.

Kiểm tra danh sách cipher suite đang bật, dùng module TLS PowerShell có sẵn:

Get-TlsCipherSuite

Vô hiệu hoá các cipher yếu — kiểm tra trước, đừng tắt mù:

# Xem 3DES còn nằm trong danh sách đang bật không
Get-TlsCipherSuite | Where-Object Name -like "*3DES*" | Select-Object Name

• Không có kết quả → bộ mã này đã tắt sẵn từ nhà sản xuất, bỏ qua lệnh dưới.
• Có kết quả → mới chạy:

Disable-TlsCipherSuite -Name "TLS_RSA_WITH_3DES_EDE_CBC_SHA"

Đưa các cipher suite TLS 1.3 lên vị trí ưu tiên cao nhất bằng PowerShell thuần — cmdlet Enable-TlsCipherSuite có tham số -Position (đã xác nhận áp dụng cho Windows Server 2022 theo tài liệu chính thức của module TLS). Điểm quan trọng: cmdlet này thao tác trên CNG Cryptographic Configuration, không cần khởi động lại máy để có hiệu lực — khác hẳn cách qua Group Policy bên dưới:

Enable-TlsCipherSuite -Name "TLS_AES_256_GCM_SHA384" -Position 0
Enable-TlsCipherSuite -Name "TLS_AES_128_GCM_SHA256" -Position 1

Lưu ý: nếu sau đó vẫn cấu hình thêm GPO "SSL Cipher Suite Order" (bên dưới), danh sách từ GPO sẽ ghi đè danh sách vừa đặt bằng PowerShell — hai cơ chế không cộng dồn với nhau, nên chọn nhất quán một cách làm cho toàn hạ tầng thay vì trộn lẫn cả hai.

Cấu hình thứ tự ưu tiên cipher suite qua Group Policy (áp dụng toàn domain cho nhiều máy cùng lúc, nhưng — khác với cách PowerShell ở trên — hiệu lực chỉ sau khi khởi động lại, theo đúng tài liệu Microsoft):

Computer Configuration → Administrative Templates → Network → SSL Configuration Settings → SSL Cipher Suite Order

Với hệ thống bắt buộc tắt hẳn TLS 1.0/1.1 và SSL 3.0 (khuyến nghị bảo mật chuẩn hiện nay, cũng là yêu cầu thường gặp khi audit PCI-DSS), cấu hình qua registry HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols theo từng giao thức (Client/Server, khoá Enabled/DisabledByDefault), hoặc dùng công cụ IIS Crypto để thao tác qua giao diện thay vì sửa tay registry — sửa sai registry SCHANNEL có thể khiến dịch vụ không khởi động được TLS, nên luôn test trên máy staging trước.

3. SMB Encryption (SMB 3.1.1) — mã hoá chia sẻ file

Theo tài liệu SMB Security Enhancements của Microsoft: mặc định, SMB 3.1.1 thương lượng AES-128-GCM. Windows Server 2022 (cùng Windows 11) là bản đầu tiên đưa thêm AES-256-GCM và AES-256-CCM, tự động thương lượng lên mức này khi cả hai đầu đều hỗ trợ, hoặc ép buộc qua Group Policy. Đây cũng là bản đầu tiên hỗ trợ AES-128-GMAC cho SMB signing (trước đó dùng AES-128-CMAC), và là bản đầu tiên cho phép SMB Direct (RDMA) mã hoá mà không làm mất lợi thế hiệu năng direct data placement như các bản cũ.

Lưu ý quan trọng (đúng theo tài liệu Microsoft): SMB Encryption không liên quan và không phụ thuộc vào BitLocker hay EFS — ba lớp này độc lập, và SMB Encryption không bảo vệ dữ liệu ở trạng thái nghỉ (at rest), chỉ bảo vệ lúc truyền — vẫn cần BitLocker cho phần đó.

Bật mã hoá cho một share cụ thể:

Set-SmbShare -Name "DuLieuKhachHang" -EncryptData $true

Bật mã hoá bắt buộc cho toàn bộ file server:

Set-SmbServerConfiguration -EncryptData $true -Force

Tạo share mới đã bật sẵn mã hoá:

New-SmbShare -Name "HopDong" -Path "D:\HopDong" -EncryptData $true

Phía client, ép buộc kết nối phải mã hoá khi map ổ mạng:

New-SmbMapping -LocalPath "Z:" -RemotePath "\\FileServer\DuLieuKhachHang" -RequirePrivacy $true

Mặc định khi bật SMB Encryption, chỉ client SMB 3.0 trở lên được phép kết nối — client SMB 1.0/2.x bị từ chối (Event ID 1003 trong log). Đừng hạ RejectUnencryptedAccess xuống $false để "cho tương thích ngược" trừ khi thật sự bắt buộc — làm vậy vô hiệu hoá toàn bộ lợi ích bảo mật vừa bật lên.

4. Mã hoá cơ sở dữ liệu — TDE và Always Encrypted (nếu chạy SQL Server trên nền Windows Server 2022)

Hai cơ chế này giải quyết hai bài toán khác nhau, không thay thế nhau:

TDE (Transparent Data Encryption): mã hoá toàn bộ file dữ liệu, log, backup ở cấp trang (page-level), mã hoá/giải mã real-time khi đọc/ghi vào đĩa. Bảo vệ khỏi tình huống ai đó đánh cắp file .mdf/.bak rồi phục hồi trên máy khác.

Điều kiện về phiên bản — kiểm tra kỹ trước khi hứa với khách:

• SQL Server 2019 trở lên: TDE có trong Standard, Enterprise, và các bản cao hơn.
• SQL Server 2017 trở xuống: TDE chỉ có trên Enterprise.
• Express: không có TDE ở bất kỳ phiên bản nào.

Kiểm tra máy đang chạy bản nào (lệnh này dùng Invoke-Sqlcmd — nếu máy chưa có, cài module SqlServer trước theo hướng dẫn ngay bên dưới rồi quay lại chạy):

Invoke-Sqlcmd -ServerInstance "localhost" -Query "SELECT SERVERPROPERTY('ProductVersion') AS Version, SERVERPROPERTY('Edition') AS Edition;"

Always Encrypted: mã hoá ngay tại client, theo từng cột dữ liệu nhạy cảm (số thẻ, CCCD, số điện thoại) — khoá mã hoá không bao giờ được tiết lộ cho SQL Server Database Engine. Đây là lớp bảo vệ cao nhất vì bảo vệ được cả khỏi chính DBA có quyền cao nhất trên server.

Chạy T-SQL từ PowerShell bằng cmdlet Invoke-Sqlcmd. Lưu ý bắt buộc: cmdlet này không có sẵn mặc định trên Windows Server — thuộc module SqlServer do Microsoft phát hành trên PowerShell Gallery, phải cài trước:

Install-Module -Name SqlServer -Force -AllowClobber -Scope AllUsers

4.1 — Kiểm tra instance đã có sẵn Master Key và Certificate chưa. Bỏ qua bước này là nguyên nhân hỏng script phổ biến nhất:

Invoke-Sqlcmd -ServerInstance "localhost" -Query "SELECT name FROM master.sys.symmetric_keys WHERE name = '##MS_DatabaseMasterKey##';"
Invoke-Sqlcmd -ServerInstance "localhost" -Query "SELECT name, expiry_date FROM master.sys.certificates WHERE name = 'TDECert';"

Lệnh thứ nhất có kết quả → instance đã có Master Key, bỏ qua lệnh CREATE MASTER KEY bên dưới. Lệnh thứ hai có kết quả → certificate đã tồn tại, đổi tên khác hoặc dùng lại.

4.2 — Tạo Master Key và Certificate. Không dùng here-string (@"..."@) vì dấu đóng bắt buộc phải nằm sát lề trái — lệch vài dấu cách khi copy từ web là lỗi cú pháp, cả khối không chạy:

Invoke-Sqlcmd -ServerInstance "localhost" -Query "CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'MatKhauManhTaiDay!2026';"
Invoke-Sqlcmd -ServerInstance "localhost" -Query "CREATE CERTIFICATE TDECert WITH SUBJECT = 'TDE Certificate cho DB KhachHang';"

4.3 — Sao lưu certificate NGAY, trước khi bật mã hoá:

Invoke-Sqlcmd -ServerInstance "localhost" -Query "BACKUP CERTIFICATE TDECert TO FILE = 'D:\Backup\TDECert.cer' WITH PRIVATE KEY (FILE = 'D:\Backup\TDECert.pvk', ENCRYPTION BY PASSWORD = 'MatKhauKhacManhHon!2026');"

4.4 — Bật mã hoá cho database:

Invoke-Sqlcmd -ServerInstance "localhost" -Database "DuLieuKhachHang" -Query "CREATE DATABASE ENCRYPTION KEY WITH ALGORITHM = AES_256 ENCRYPTION BY SERVER CERTIFICATE TDECert;"
Invoke-Sqlcmd -ServerInstance "localhost" -Database "DuLieuKhachHang" -Query "ALTER DATABASE DuLieuKhachHang SET ENCRYPTION ON;"

Cách xác nhận:

Invoke-Sqlcmd -ServerInstance "localhost" -Query "SELECT name, is_encrypted FROM sys.databases WHERE name = 'DuLieuKhachHang';"
Invoke-Sqlcmd -ServerInstance "localhost" -Query "SELECT encryption_state, percent_complete FROM sys.dm_database_encryption_keys;"

is_encrypted phải là 1, encryption_state phải là 3.

Always Encrypted thường thiết lập qua wizard trong SQL Server Management Studio (chuột phải database → Tasks → Encrypt Columns) vì cần chọn cột, chọn loại mã hoá (Deterministic cho phép so sánh/join, Randomized bảo mật cao hơn nhưng không query trực tiếp được) và nơi lưu Column Master Key (Windows Certificate Store hoặc Azure Key Vault) — nên làm qua giao diện thay vì T-SQL thuần để tránh sai cấu hình key.

5. Secure Boot, TPM 2.0, Virtualization-based Security & Credential Guard

Đây là các lớp bảo vệ nền tảng — nếu bị bỏ qua, mã hoá bên trên vẫn có thể bị vô hiệu hoá bởi mã độc chèn vào lúc khởi động hoặc bằng cách đọc trộm bộ nhớ RAM lúc máy đang chạy. Windows Server 2022 gộp các lớp này thành mô hình Secured-core server, yêu cầu phần cứng: CPU hỗ trợ ảo hoá (Intel VT-x/AMD-V), UEFI có Secure Boot, và TPM 2.0.

• Secure Boot: xác minh chữ ký số của UEFI firmware, driver và hệ điều hành lúc khởi động — chặn bootkit/rootkit chèn vào trước khi Windows kịp load.
• TPM 2.0: chip mã hoá phần cứng lưu khoá và số đo toàn vẹn hệ thống — là điều kiện để BitLocker (mục 1) đạt mức bảo vệ cao nhất.
• VBS (Virtualization-based Security): dùng chính hypervisor để tạo một vùng bộ nhớ cách ly, tiến trình thường (kể cả tiến trình chạy quyền admin) không đọc được.
• Credential Guard: chạy trên nền VBS, cách ly NTLM hash, vé Kerberos (TGT) khỏi vùng nhớ thông thường — chặn kỹ thuật đánh cắp thông tin đăng nhập kiểu Pass-the-Hash/Pass-the-Ticket phổ biến trong tấn công leo thang quyền sau khi xâm nhập.

Lưu ý quan trọng theo đúng khuyến cáo chính thức của Microsoft: Credential Guard nên được bật trước khi máy join domain, hoặc trước lần đăng nhập domain user đầu tiên — nếu bật sau khi máy đã join domain và đã có người đăng nhập, thông tin đăng nhập (credential) trên máy đó có thể đã bị lộ từ trước; bật Credential Guard lúc này bảo vệ cho các lần đăng nhập tiếp theo, chứ không "xoá" được rủi ro đã phát sinh trước đó.

(Get-CimInstance Win32_ComputerSystem).DomainRole
# 4 hoặc 5 = Domain Controller -> KHÔNG bật Credential Guard trên máy này.

Các lớp còn lại trong bài (Secure Boot, TPM, BitLocker, TLS, SMB Encryption) vẫn áp dụng bình thường cho DC.

Kiểm tra trạng thái Secure Boot đang bật hay tắt:

Confirm-SecureBootUEFI

(trả về True nếu máy hỗ trợ UEFI và Secure Boot đang bật; báo lỗi "Cmdlet not supported on this platform" nếu máy vẫn ở chế độ BIOS/Legacy — cần chuyển UEFI trước. Lưu ý: đây chỉ là cmdlet để ĐỌC trạng thái — không có cmdlet PowerShell nào để BẬT Secure Boot từ trong Windows, vì đây là cấu hình nằm ở tầng firmware/UEFI, ngoài tầm với của hệ điều hành đang chạy; phải vào menu UEFI của máy để bật.)

Bật Credential Guard qua Group Policy (khuyến nghị cho môi trường domain, áp dụng đồng loạt nhiều máy):

Computer Configuration → Administrative Templates → System → Device Guard → Turn On Virtualization Based Security → chọn Enabled, rồi chọn chế độ ở mục Credential Guard Configuration:

Microsoft ghi rõ trong tài liệu: "If you want to be able to turn off Credential Guard remotely, choose the option Enabled without lock." Quy trình gỡ UEFI lock bắt buộc có mặt vật lý tại máy để bấm phím xác nhận trước khi hệ điều hành khởi động — không làm từ xa được bằng bất kỳ cách nào.

Bật bằng registry qua PowerShell (thay cho GPO, hợp khi cấu hình một máy đơn lẻ hoặc đưa vào script triển khai):

New-Item -Path "HKLM:\SYSTEM\CurrentControlSet\Control\DeviceGuard" -Force | Out-Null
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\DeviceGuard" -Name "EnableVirtualizationBasedSecurity" -Value 1 -Type DWord
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\DeviceGuard" -Name "RequirePlatformSecurityFeatures" -Value 1 -Type DWord

# LsaCfgFlags = 2 -> Enabled WITHOUT lock (tắt lại được từ xa) - NÊN DÙNG cho máy đặt xa.
# LsaCfgFlags = 1 -> Enabled WITH UEFI lock - chỉ dùng khi ra tận máy được.
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name "LsaCfgFlags" -Value 2 -Type DWord

Restart-Computer

(RequirePlatformSecurityFeatures = 1 nghĩa là yêu cầu Secure Boot; dùng = 3 nếu muốn yêu cầu thêm cả DMA protection trên phần cứng hỗ trợ.)

Đường lùi nếu Credential Guard gây xung đột (chỉ dùng được khi đã bật ở chế độ without lock):

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name "LsaCfgFlags" -Value 0 -Type DWord
Restart-Computer

Lưu ý: phải đặt giá trị về 0, xoá hẳn khoá registry có thể không tắt được Credential Guard.

Xác nhận Credential Guard đang thật sự chạy bằng PowerShell:

(Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard).SecurityServicesRunning

Lệnh trả về một danh sách số, không phải một số duy nhất: 1 = Credential Guard đang chạy, 2 = HVCI (bảo vệ toàn vẹn nhân hệ điều hành) đang chạy, có thể ra 1 2 nếu cả hai cùng bật, và không trả về gì hoặc trả về 0 nghĩa là chưa có lớp nào chạy. Chú ý: nếu chỉ thấy 2 mà không có 1 thì Credential Guard chưa chạy — dễ nhìn nhầm thành đã xong. Đối chiếu thêm bằng msinfo32.exe, xem dòng "Virtualization-based Security Services Running" có chữ Credential Guard hay không.

Lưu ý vận hành: bật VBS/Credential Guard tiêu tốn thêm một phần RAM/CPU cho vùng cách ly, và một số driver cũ hoặc phần mềm ảo hoá lồng nhau (nested virtualization) có thể xung đột — luôn test trên máy staging trước khi áp dụng cho máy chủ production đang phục vụ khách.

6. EFS (Encrypting File System) — mã hoá theo file, theo người dùng

Khác hẳn BitLocker, EFS mã hoá từng file/thư mục cụ thể, gắn với tài khoản người dùng Windows (không phải với máy) — chỉ hoạt động trên NTFS.

Bật qua giao diện: chuột phải file/thư mục → Properties → Advanced → tick "Encrypt contents to secure data".

Bật qua dòng lệnh (hữu ích khi cần áp dụng hàng loạt qua script):

cipher /e /a /s:"D:\HopDongKhachHang"

Kiểm tra từng file đã thật sự được mã hoá chưa:

cipher "D:\HopDongKhachHang\*"

Đọc kết quả theo từng dòng: mỗi file phải bắt đầu bằng chữ E. Còn dòng nào chữ U nghĩa là file đó chưa được mã hoá.

Đường lùi — gỡ mã hoá cả thư mục nếu cần:

cipher /d /a /s:"D:\HopDongKhachHang"

(Với máy chủ nhiều người dùng, mã hoá hàng loạt an toàn cần thiết lập thêm Data Recovery Agent trước — quy trình đầy đủ nằm ở Bước 9 của Checklist bên dưới.)

Bảng so sánh nhanh: khi nào dùng BitLocker, khi nào dùng EFS

Hai lớp này không loại trừ nhau — một máy chủ nhiều người dùng hoàn toàn có thể vừa bật BitLocker cho cả ổ đĩa (chống mất thiết bị), vừa bật EFS cho các thư mục nhạy cảm của từng nhân viên (chống nội bộ đọc trộm lẫn nhau).

Bối cảnh bảo mật tổng thể (ngắn gọn — không phải trọng tâm bài)

Mã hoá là lớp bảo vệ dữ liệu cốt lõi, nhưng không đứng một mình. Vài việc nên làm kèm theo trên Windows Server 2022 — chi tiết lệnh thực thi cho các mục này nằm trong Bước 1 và Bước 10 của Checklist ngay dưới đây:

• Windows Update quản lý qua WSUS/Windows Admin Center — vá lỗ hổng định kỳ, đừng để máy chủ chạy bản vá cũ hàng tháng.
• Windows Defender bật Real-time protection và Tamper Protection — đừng tắt để "cho nhẹ máy".
• RDP hardening — bật Network Level Authentication (NLA), giới hạn IP được kết nối qua Windows Firewall, và tốt nhất là không mở RDP thẳng ra Internet mà đi qua VPN hoặc RD Gateway; nếu buộc phải mở thì thêm xác thực nhiều lớp (MFA). Riêng việc đổi cổng 3389 sang cổng khác chỉ làm giảm số lần bị dò tự động, không thực sự tăng bảo mật; đừng coi đó là biện pháp bảo vệ. Chi tiết lệnh ở Bước 10 của Checklist.
• Windows Firewall cấu hình theo nguyên tắc chỉ mở đúng port cần thiết, không "Allow All" cho tiện.

Đây là các lớp bổ trợ — bài này tập trung vào mã hoá vì đó là lớp phòng thủ cuối cùng: dù các lớp trên có bị vượt qua, dữ liệu đã mã hoá đúng cách vẫn vô dụng với kẻ tấn công.

Checklist triển khai 6 lớp mã hoá — theo đúng thứ tự

Các mục 1-6 ở trên trình bày từng lớp mã hoá riêng lẻ. Nhưng thứ tự bật lên cũng quan trọng không kém — bật sai thứ tự có thể gây khoá mất máy, mất dữ liệu vĩnh viễn, hoặc gián đoạn dịch vụ cho người dùng đang dùng hệ thống.

Bước 0 — Sao lưu toàn bộ và xác nhận có đường vào dự phòng ⚠️ KHÔNG ĐƯỢC BỎ QUA

Đây là bước duy nhất trong danh sách này mà bỏ qua nó sẽ biến mọi sai sót nhỏ ở các bước sau thành mất dữ liệu hoặc mất luôn máy chủ. Trong 10 bước phía dưới có ít nhất ba bước có thể khoá bạn ra khỏi chính máy của mình (Bước 4, 5, 10) và ba bước có thể làm mất dữ liệu vĩnh viễn nếu mất khoá (Bước 5, 8, 9).

Việc cần làm:

1. Sao lưu toàn bộ máy chủ và kiểm chứng bản sao lưu phục hồi được. Có file backup chưa đủ — phải thử phục hồi ra một máy khác và xác nhận nó bật lên được.

2. Xác nhận đường vào ngoài mạng đang hoạt động. iDRAC/iLO của máy chủ, hoặc console/KVM của nhà cung cấp hạ tầng — mở thử ngay bây giờ, đăng nhập được, nhìn thấy màn hình máy.

3. Ghi lại cấu hình hiện tại để so sánh về sau:

$luu = "D:\Backup\hien-trang-truoc-khi-ma-hoa.txt"
"=== Cipher suite ===" | Out-File $luu
Get-TlsCipherSuite | Select-Object -ExpandProperty Name | Out-File $luu -Append
"=== SMB Server ===" | Out-File $luu -Append
Get-SmbServerConfiguration | Out-File $luu -Append
"=== Firewall (Remote Desktop) ===" | Out-File $luu -Append
Get-NetFirewallRule -DisplayGroup "Remote Desktop" | Select-Object DisplayName, Enabled, Direction, Action | Out-File $luu -Append
"=== BitLocker ===" | Out-File $luu -Append
Get-BitLockerVolume | Out-File $luu -Append

Rồi chép file này ra khỏi máy chủ.

4. Chọn cửa sổ thời gian và báo trước cho người dùng. Nên làm ngoài giờ hoặc cuối tuần.

5. Có người thứ hai biết việc bạn đang làm và có số điện thoại liên lạc được.

Cách xác nhận trước khi sang Bước 1: trả lời được "có" cho cả bốn câu: Đã có bản sao lưu và đã thử phục hồi chưa? Đã mở được console/iDRAC chưa? Đã lưu hiện trạng ra ngoài máy chủ chưa? Đã báo người dùng chưa? Còn một câu "chưa" thì dừng lại.

Bước 1 — Cập nhật Windows Update trước khi khoá cứng bất kỳ cấu hình nào

Việc cần làm: Cài đầy đủ bản vá Windows Update mới nhất trước khi đụng vào bất kỳ tính năng bảo mật nào ở các bước sau.

Vì sao: Các bước sau (Secure Boot, TPM, BitLocker, VBS) phụ thuộc vào trạng thái ổn định của hệ điều hành và firmware.

Cách thực thi — có 3 đường, đều là cách chính thức:

(a) WSUS hoặc Windows Admin Center — cách chuẩn cho môi trường nhiều máy, quản lý tập trung.

(b) sconfig — công cụ cấu hình máy chủ có sẵn, có tài liệu chính thức trên Microsoft Learn. Gõ sconfig, chọn mục 6 — Download and Install Updates.

(c) Windows Update Agent API (WUA) — cách lập trình chính thức dùng trong PowerShell. Microsoft ghi rõ: script mẫu không được hỗ trợ, nhưng bản thân bộ API thì được hỗ trợ chính thức.

$phien   = New-Object -ComObject Microsoft.Update.Session
$timKiem = $phien.CreateUpdateSearcher()
$ketQua  = $timKiem.Search("IsInstalled=0 and Type='Software' and IsHidden=0")
$ketQua.Updates | Select-Object Title

$danhSach = New-Object -ComObject Microsoft.Update.UpdateColl
foreach ($u in $ketQua.Updates) {
    if (-not $u.EulaAccepted) { $u.AcceptEula() }
    $null = $danhSach.Add($u)
}

$taiVe = $phien.CreateUpdateDownloader()
$taiVe.Updates = $danhSach
$null = $taiVe.Download()

$caiDat = $phien.CreateUpdateInstaller()
$caiDat.Updates = $danhSach
$ketQuaCai = $caiDat.Install()
$ketQuaCai.ResultCode      # 2 = thành công
$ketQuaCai.RebootRequired  # True = phải khởi động lại

Về UsoClient.exe: không có trang tài liệu nào trên Microsoft Learn, hành vi thay đổi giữa các bản Windows. Đã có WUA API và sconfig là đường chính thức thì không có lý do gì dùng UsoClient.

Cách xác nhận:

Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 10 HotFixID, InstalledOn

$phien   = New-Object -ComObject Microsoft.Update.Session
$ketQua  = $phien.CreateUpdateSearcher().Search("IsInstalled=0 and Type='Software' and IsHidden=0")
$ketQua.Updates.Count   # 0 = không còn bản vá nào thiếu

Bước 2 — Xác nhận firmware ở chế độ UEFI native (không Legacy/CSM)

• Việc cần làm: Vào BIOS/UEFI kiểm tra Boot Mode = UEFI, tắt Legacy/CSM. Máy đang Legacy thì dùng mbr2gpt.exe chuyển đổi phân vùng trước.
• Vì sao: TPM 2.0 không hoạt động đúng trong Legacy/CSM. Đổi mode sau khi đã cài Legacy mà chưa chuyển đổi phân vùng sẽ khiến máy không boot được.
• Cách thực thi: Đây là cấu hình firmware — Windows không có cmdlet PowerShell nào để tự bật/đổi chế độ boot UEFI. Bắt buộc vào menu UEFI thủ công.
• Cách xác nhận: Confirm-SecureBootUEFI không báo lỗi "Cmdlet not supported on this platform".

Bước 3 — Bật Secure Boot và xác nhận TPM 2.0 sẵn sàng

Việc cần làm: Bật Secure Boot trong UEFI. Chạy Get-Tpm xác nhận TPM sẵn sàng.

Vì sao (⚠️ điểm dễ sai nghiêm trọng): Theo BitLocker recovery overview của Microsoft, thay đổi cấu hình Secure Boot/firmware sau khi BitLocker đã bật có thể đẩy máy vào chế độ recovery (yêu cầu khoá 48 ký tự). Phải chốt xong bước này trước Bước 5.

Cách thực thi: Không có cmdlet PowerShell bật được Secure Boot từ trong Windows — Confirm-SecureBootUEFI chỉ ĐỌC, không SET được. Đây là chủ đích thiết kế bảo mật.

Cách xác nhận:

Confirm-SecureBootUEFI   # phải trả về True
Get-Tpm                  # TpmPresent: True, TpmReady: True

⚠️ Quy tắc phải nhớ suốt đời máy chủ này — mọi lần đụng vào firmware về sau: sau khi BitLocker đã bật (Bước 5), mỗi lần cập nhật BIOS/UEFI, đổi cấu hình Secure Boot, thay bo mạch chủ, phải tạm dừng BitLocker trước:

Suspend-BitLocker -MountPoint "C:" -RebootCount 2
# Làm xong việc với firmware thì bật lại:
Resume-BitLocker -MountPoint "C:"
manage-bde -status C:     # Protection Status phải là: Protection On

⚠️ Nếu máy chủ của bạn là máy ảo (cloud, VPS, Hyper-V, VMware): chạy Get-Tpm trước tiên. Kết quả TpmPresent: False nghĩa là máy ảo này chưa được cấp TPM ảo (vTPM) — đa số máy ảo không bật sẵn tính năng này. Hãy liên hệ nhà cung cấp hạ tầng yêu cầu bật vTPM trước khi đi tiếp, vì Bước 4 và Bước 5 đều phụ thuộc vào nó. Đừng chuyển sang phương án BitLocker dùng khoá khởi động trên USB cho máy chủ production — cách đó mất khả năng kiểm tra toàn vẹn hệ thống lúc khởi động, và với máy ảo trên cloud thì càng không khả thi.

Bước 4 — Bật VBS và Credential Guard (test trên staging trước)

(Get-CimInstance Win32_ComputerSystem).DomainRole
# 4 hoặc 5 = Domain Controller -> dừng lại, không làm bước này

Việc cần làm: Bật Virtualization-based Security + Credential Guard.

Vì sao (⚠️ điểm dễ sai nghiêm trọng): Phụ thuộc Secure Boot + TPM ổn định ở Bước 3. Driver cũ/ảo hoá lồng nhau có thể xung đột — luôn test staging trước. Nếu máy sắp join domain, bật Credential Guard trước khi join.

Cách thực thi (mặc định dùng LsaCfgFlags = 2 — Enabled without lock, tắt lại được từ xa nếu xung đột; chỉ đổi sang = 1 nếu ra tận máy được trong vài giờ — xem bảng lựa chọn đầy đủ ở mục 5, Phần 2):

New-Item -Path "HKLM:\SYSTEM\CurrentControlSet\Control\DeviceGuard" -Force | Out-Null
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\DeviceGuard" -Name "EnableVirtualizationBasedSecurity" -Value 1 -Type DWord
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\DeviceGuard" -Name "RequirePlatformSecurityFeatures" -Value 1 -Type DWord
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name "LsaCfgFlags" -Value 2 -Type DWord
Restart-Computer

Đường lùi nếu gây xung đột (chỉ dùng được với chế độ without lock ở trên):

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name "LsaCfgFlags" -Value 0 -Type DWord
Restart-Computer

Cách xác nhận:

(Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard).SecurityServicesRunning

Lệnh trả về một danh sách số: 1 = Credential Guard đang chạy, 2 = HVCI đang chạy (có thể ra 1 2 nếu cả hai cùng bật). Chỉ thấy 2 mà không có 1 nghĩa là Credential Guard chưa chạy — dễ nhìn nhầm thành đã xong.

Bước 5 — Bật BitLocker và sao lưu khoá phục hồi NGAY LẬP TỨC

Việc cần làm: Bật BitLocker XtsAes256 + TPM protector, tạo khoá phục hồi, rồi sao lưu khoá đó vào AD — cả bốn việc trong cùng một phiên làm việc, trước khi khởi động lại máy.

Vì sao (⚠️ điểm dễ sai nghiêm trọng nhất): -TpmProtector không tự sinh khoá phục hồi — thiếu bước tạo khoá phục hồi riêng thì không có gì để sao lưu. Và nếu máy khởi động lại giữa lúc bật BitLocker và lúc backup khoá xong, có thể bị đẩy vào recovery mode mà không ai có khoá mở — mất dữ liệu vĩnh viễn. Quy trình đầy đủ (gồm cả bước kiểm tra và in khoá ra bản ngoài hệ thống) xem mục 1, Phần 2.

Cách thực thi — HAI giai đoạn riêng, đừng chạy chung một khối:

Giai đoạn 1 — cài tính năng, máy sẽ khởi động lại ngay tại đây:

Install-WindowsFeature BitLocker -IncludeAllSubFeature -IncludeManagementTools -Restart

Giai đoạn 2 — sau khi máy đã lên lại, đăng nhập rồi chạy trọn khối 4 lệnh này trong CÙNG một phiên, không xen bất kỳ lệnh khởi động lại nào ở giữa:

Enable-BitLocker -MountPoint "C:" -EncryptionMethod XtsAes256 -TpmProtector
Add-BitLockerKeyProtector -MountPoint "C:" -RecoveryPasswordProtector
$idKhoaPhucHoi = (Get-BitLockerVolume -MountPoint "C:").KeyProtector |
    Where-Object { $_.KeyProtectorType -eq 'RecoveryPassword' } |
    Select-Object -ExpandProperty KeyProtectorId
Backup-BitLockerKeyProtector -MountPoint "C:" -KeyProtectorId $idKhoaPhucHoi

Cách xác nhận: manage-bde -protectors -get C: phải liệt kê hai protector (TPM và Numerical Password) — chỉ thấy TPM nghĩa là chưa có khoá phục hồi, phải làm lại. Sau đó manage-bde -status C: (100%, Protection: On); AD Users and Computers → BitLocker Recovery tab phải thấy recovery password (cần cài RSAT-Feature-Tools-BitLocker-BdeAducExt để nhìn thấy tab này).

Bước 6 — Cấu hình TLS 1.3 và loại bỏ cipher yếu

Việc cần làm: Tắt cipher yếu, đưa TLS 1.3 lên ưu tiên cao nhất.

Cách thực thi:

Get-TlsCipherSuite | Where-Object Name -like "*3DES*" | Select-Object Name
# Có kết quả mới chạy dòng dưới; không có thì bộ mã này đã tắt sẵn:
Disable-TlsCipherSuite -Name "TLS_RSA_WITH_3DES_EDE_CBC_SHA"

Enable-TlsCipherSuite -Name "TLS_AES_256_GCM_SHA384" -Position 0
Enable-TlsCipherSuite -Name "TLS_AES_128_GCM_SHA256" -Position 1

Vì sao: Không phụ thuộc kỹ thuật vào các bước trên, có thể làm độc lập. Nhưng có rủi ro làm hỏng dịch vụ đang chạy: danh sách ưu tiên tự đặt sẽ loại bỏ mọi bộ mã không nằm trong đó, và website HTTP/2 có thể lỗi nếu thiếu bộ mã tương thích. Tài liệu Microsoft cũng không thống nhất về việc có cần khởi động lại hay không — nên luôn coi như cần và kiểm chứng lại.

Cách xác nhận (làm cả 3, không dừng ở bước 1):

• 1. Get-TlsCipherSuite | Select-Object -First 2 — hai dòng đầu phải là hai bộ mã TLS 1.3.
• 2. Khởi động lại dịch vụ web (hoặc cả máy), mở website bằng trình duyệt xác nhận vẫn lên bình thường.
• 3. Quét bằng công cụ kiểm tra TLS từ bên ngoài.

Đường lùi: ghi lại danh sách cipher trước khi sửa: Get-TlsCipherSuite | Select-Object -ExpandProperty Name | Out-File D:\Backup\cipher-truoc-khi-sua.txt.

Bước 7 — Bật SMB Encryption: gỡ SMB 1.0 trước, test một share, rồi mới ép buộc toàn server

Việc cần làm: (1) Rà và gỡ SMB 1.0; (2) Bật mã hoá cho một share test; (3) Theo dõi; (4) Mới ép buộc toàn server.

⚠️ Vì sao phải gỡ SMB 1.0 trước: cơ chế chống hạ cấp của SMB 3.1.1 không ngăn được việc hạ cấp xuống SMB 1.0 — mà hạ cấp xuống SMB 1.0 thì dữ liệu đi không mã hoá.

Get-WindowsFeature FS-SMB1
Set-SmbServerConfiguration -AuditSmb1Access $true -Force
Get-WinEvent -LogName Microsoft-Windows-SMBServer/Audit -MaxEvents 50
# Không còn ai dùng (sau 1-2 tuần theo dõi) thì mới gỡ hẳn
Uninstall-WindowsFeature FS-SMB1 -Restart

⚠️ Điểm dễ gây gián đoạn nhất — danh sách thiết bị hay chết sau khi bật mã hoá toàn server: máy photocopy/máy in đa năng có scan-to-folder, NAS đời cũ, đầu ghi camera/máy chấm công, máy Linux/Mac dùng Samba cũ, phần mềm sao lưu đời cũ, máy Windows 7/Server 2008 R2. Lập danh sách trước, kiểm tra từng cái, rồi mới ép buộc.

⚠️ Nếu máy chủ này là Domain Controller: ép mã hoá toàn server sẽ áp lên cả SYSVOL và NETLOGON — máy trạm không hỗ trợ sẽ không tải được Group Policy. Với DC, chỉ bật mã hoá theo từng share dữ liệu, đừng dùng lệnh ép toàn server.

Cách thực thi:

Set-SmbShare -Name "TestShare" -EncryptData $true -Force

# Theo dõi vài ngày
Get-WinEvent -LogName Microsoft-Windows-SmbServer/Operational -MaxEvents 100 | Where-Object Id -eq 1003

# Không có Event 1003 nào, và máy KHÔNG phải Domain Controller, thì mới:
Set-SmbServerConfiguration -EncryptData $true -Force

Cách xác nhận: Get-SmbServerConfiguration | Select-Object EncryptData, EnableSMB1Protocol, RejectUnencryptedAccess — mong muốn: EncryptData = True, EnableSMB1Protocol = False, RejectUnencryptedAccess = True.

Đường lùi:

Set-SmbServerConfiguration -EncryptData $false -Force
Set-SmbShare -Name "TenShare" -EncryptData $false -Force

Bước 8 — Bật TDE cho SQL Server, backup certificate NGAY SAU KHI TẠO — trước khi bật mã hoá

Việc cần làm: Tạo Master Key + Certificate → backup certificate ra ngoài server ngay → rồi mới tạo Database Encryption Key và bật mã hoá. Đúng thứ tự này, không đảo ngược.

Vì sao (⚠️ mức nghiêm trọng tương đương BitLocker): Nếu bật mã hoá TRƯỚC khi backup certificate mà máy gặp sự cố lúc đó, database bị mã hoá vĩnh viễn không đọc được nữa, kể cả phục hồi từ file .bak — vì bản backup đó cũng được mã hoá bằng chính certificate chưa kịp sao lưu. Quy trình đầy đủ (gồm bước kiểm tra master key/certificate có sẵn chưa) xem mục 4, Phần 2.

Cách thực thi (⚠️ đổi 2 mật khẩu ví dụ dưới đây thành mật khẩu riêng của bạn trước khi chạy — đừng copy nguyên văn, xem chi tiết ở mục 4, Phần 2):

Install-Module -Name SqlServer -Force -AllowClobber -Scope AllUsers

Invoke-Sqlcmd -ServerInstance "localhost" -Query "CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'MatKhauManhTaiDay!2026';"
Invoke-Sqlcmd -ServerInstance "localhost" -Query "CREATE CERTIFICATE TDECert WITH SUBJECT = 'TDE Certificate cho DB KhachHang';"

# Backup NGAY — trước khi bật mã hoá ở bước dưới
Invoke-Sqlcmd -ServerInstance "localhost" -Query "BACKUP CERTIFICATE TDECert TO FILE = 'D:\Backup\TDECert.cer' WITH PRIVATE KEY (FILE = 'D:\Backup\TDECert.pvk', ENCRYPTION BY PASSWORD = 'MatKhauKhacManhHon!2026');"
# Chép TDECert.cer + TDECert.pvk ra ngoài máy chủ này ngay bây giờ, rồi mới chạy tiếp:

Invoke-Sqlcmd -ServerInstance "localhost" -Database "DuLieuKhachHang" -Query "CREATE DATABASE ENCRYPTION KEY WITH ALGORITHM = AES_256 ENCRYPTION BY SERVER CERTIFICATE TDECert;"
Invoke-Sqlcmd -ServerInstance "localhost" -Database "DuLieuKhachHang" -Query "ALTER DATABASE DuLieuKhachHang SET ENCRYPTION ON;"

Cách xác nhận:

Invoke-Sqlcmd -ServerInstance "localhost" -Query "SELECT name, is_encrypted FROM sys.databases WHERE name = 'DuLieuKhachHang';"
Invoke-Sqlcmd -ServerInstance "localhost" -Query "SELECT encryption_state, percent_complete FROM sys.dm_database_encryption_keys;"

is_encrypted phải là 1, encryption_state phải là 3. Và xác nhận thủ công: hai file TDECert.cer/TDECert.pvk đã nằm ở nơi lưu trữ tách biệt khỏi máy chủ này.

Bước 9 — Áp EFS cho thư mục/người dùng cụ thể (nếu cần)

⚠️ Vì sao bước này nguy hiểm hơn vẻ ngoài: EFS gắn khoá vào tài khoản người dùng, không gắn vào máy. Nhân viên nghỉ việc, tài khoản bị xoá, profile hỏng, chứng chỉ mất — là file mất vĩnh viễn. Phải thiết lập Data Recovery Agent (DRA) TRƯỚC khi mã hoá bất kỳ file nào.

9.1 — Tạo chứng chỉ Data Recovery Agent:

cipher /r:D:\Backup\EFS-DRA

9.2 — Công bố DRA cho toàn miền qua Group Policy: Computer Configuration → Windows Settings → Security Settings → Public Key Policies → Encrypting File System → Add Data Recovery Agent → nạp EFS-DRA.cer. Chạy gpupdate /force.

9.3 — Mã hoá thư mục (sau khi DRA đã có hiệu lực):

cipher /e /a /s:"D:\HopDongKhachHang"

9.4 — Sao lưu chứng chỉ EFS của từng người dùng:

cipher /x "D:\Backup\EFS-cert-nhanvienA"

9.5 — Nếu có file đã mã hoá TRƯỚC khi thêm DRA:

cipher /u

Cách xác nhận:

cipher "D:\HopDongKhachHang\*"
cipher /c "D:\HopDongKhachHang\HopDong-2026-001.docx"

Kết quả phải liệt kê cả người dùng sở hữu lẫn Recovery Certificate (DRA). Chỉ thấy người dùng mà không thấy DRA thì dừng lại, xử lý bước 9.2 trước.

⚠️ EFS không hợp với thư mục chia sẻ qua mạng. EFS chỉ nên dùng cho máy chủ có nhiều người đăng nhập trực tiếp vào (kiểu Remote Desktop Services). Muốn bảo vệ thư mục chia sẻ qua mạng thì dùng BitLocker + SMB Encryption + phân quyền NTFS.

Đường lùi: cipher /d /a /s:"D:\HopDongKhachHang".

Bước 10 — Hoàn thiện lớp hardening tổng thể và xác nhận toàn bộ

⚠️ Lời khuyên thật lòng trước khi làm: cách an toàn nhất không phải là mở RDP ra Internet rồi lọc IP, mà là không mở RDP ra Internet. Nếu có VPN, để RDP chỉ nghe trong mạng nội bộ. Đổi cổng 3389 sang cổng khác gần như không tăng bảo mật — công cụ quét cổng tìm ra trong vài phút. Ưu tiên: VPN > giới hạn IP > MFA > NLA, đổi cổng xếp cuối và có thể bỏ qua.

10.1 — Windows Defender:

Set-MpPreference -DisableRealtimeMonitoring $false

Tamper Protection: KHÔNG có lệnh PowerShell/registry nào bật/tắt được — chủ đích thiết kế của Microsoft. Chỉ bật qua Windows Security app hoặc Intune.

10.2 — Bật NLA cho RDP:

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name "UserAuthentication" -Value 1

10.3 — Xác định đúng IP đang kết nối:

Get-NetTCPConnection -LocalPort 3389 -State Established | Select-Object RemoteAddress, RemotePort
quser

10.4 — Tạo luật cho phép trước:

New-NetFirewallRule -DisplayName "RDP - Chi IP van phong" -Direction Inbound -Protocol TCP -LocalPort 3389 -RemoteAddress "203.0.113.10","203.0.113.20" -Action Allow

10.5 — ĐẶT LƯỚI AN TOÀN trước khi siết (tự mở lại sau 15 phút):

$hanhDong = New-ScheduledTaskAction -Execute 'powershell.exe' -Argument '-NoProfile -Command "Enable-NetFirewallRule -DisplayGroup ''Remote Desktop''; Set-NetFirewallProfile -Profile Domain,Public,Private -DefaultInboundAction NotConfigured"'
$thoiDiem = New-ScheduledTaskTrigger -Once -At (Get-Date).AddMinutes(15)
Register-ScheduledTask -TaskName "CUU-HO-RDP" -Action $hanhDong -Trigger $thoiDiem -User "SYSTEM" -RunLevel Highest -Force

10.6 — Giờ mới siết:

Disable-NetFirewallRule -DisplayGroup "Remote Desktop"
Set-NetFirewallProfile -Profile Domain,Public,Private -DefaultInboundAction Block -DefaultOutboundAction Allow

10.7 — Kiểm chứng rồi mới gỡ lưới an toàn. Mở MỘT PHIÊN RDP MỚI từ máy khác, đăng nhập thành công, rồi mới:

Unregister-ScheduledTask -TaskName "CUU-HO-RDP" -Confirm:$false

Cách xác nhận toàn bộ (sau khi vào lại được bằng phiên mới):

Confirm-SecureBootUEFI
Get-Tpm
(Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard).SecurityServicesRunning
manage-bde -status C:
manage-bde -protectors -get C:
Get-TlsCipherSuite | Select-Object -First 2
Get-SmbServerConfiguration | Select-Object EncryptData, EnableSMB1Protocol, RejectUnencryptedAccess
Get-MpComputerStatus | Select-Object RealTimeProtectionEnabled, IsTamperProtected
Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name UserAuthentication
Get-NetFirewallRule -DisplayName "RDP - Chi IP van phong" | Select-Object DisplayName, Enabled, Action
Get-ScheduledTask -TaskName "CUU-HO-RDP" -ErrorAction SilentlyContinue   # Phải KHÔNG còn kết quả

Ngoài lệnh: mở được phiên RDP mới từ IP đã cho phép, không mở được từ IP khác.

Đường lùi (khi đã lỡ bị khoá ra ngoài): vào qua console/iDRAC, chạy:

Enable-NetFirewallRule -DisplayGroup "Remote Desktop"
Set-NetFirewallProfile -Profile Domain,Public,Private -DefaultInboundAction NotConfigured
Remove-NetFirewallRule -DisplayName "RDP - Chi IP van phong" -ErrorAction SilentlyContinue

Không có console/iDRAC thì không còn cách nào từ xa — phải ra tận nơi hoặc nhờ kỹ thuật viên bên cho thuê hạ tầng.

Tổng kết: Làm xong đủ các bước theo đúng thứ tự, máy chủ đã bật các lớp mã hoá chính mà Windows Server 2022 cung cấp sẵn — bảo vệ dữ liệu lúc nằm trên ổ đĩa, lúc đi qua mạng, lúc nằm trong cơ sở dữ liệu, cộng với lớp nền bảo vệ quá trình khởi động và thông tin đăng nhập. Không cần mua thêm phần mềm bên thứ ba cho những lớp này.

Nhưng nói cho đúng: đây là các lớp mã hoá, không phải toàn bộ bảo mật của máy chủ. Mã hoá làm dữ liệu bị lấy trở nên vô dụng — nó không ngăn được việc bị lấy, và không cứu được dữ liệu bị xoá. Những việc sau mã hoá không thay thế được, phải làm song song:

• Sao lưu có khả năng chống ransomware. Mã hoá không cứu được bạn khỏi ransomware — ransomware mã hoá đè lên dữ liệu của bạn, khác với việc bảo vệ khỏi bị đọc trộm. Cần bản sao lưu ở nơi kẻ tấn công không xoá được, và đã thử phục hồi thật.
• Quản lý mật khẩu quản trị viên cục bộ (Windows LAPS). Dùng chung một mật khẩu Administrator cho tất cả máy là con đường lây lan nhanh nhất.
• Nhật ký và giám sát (audit log). Không có nhật ký thì khi xảy ra sự cố không trả lời được "ai đã vào, lúc nào, lấy gì".
• Vá SQL Server riêng. Windows Update không tự vá SQL Server.
• Gỡ hẳn SMB 1.0 (đã nói ở Bước 7).
• HVCI / Memory Integrity — lớp bảo vệ nhân hệ điều hành đi kèm VBS, nên bật thêm sau khi test tương thích driver.
• Ký và bảo vệ kênh LDAP, IPsec cho lưu lượng nội bộ, kiểm soát truy cập quản trị.

Nói cách khác: mã hoá là điều kiện cần, không phải điều kiện đủ.

Câu hỏi thường gặp

Bật BitLocker rồi, máy chủ tự khởi động lại được không hay phải nhập khoá mỗi lần? Nếu dùng TPM protector và không có thay đổi phần cứng/firmware đáng ngờ, máy tự mở khoá khi boot.

Mất khoá phục hồi BitLocker thì sao? Còn tuỳ vào việc máy có đang khởi động bình thường hay không. Nếu máy vẫn boot và mở khoá được bằng TPM, bạn tạo lại khoá phục hồi mới ngay được bằng Add-BitLockerKeyProtector -MountPoint "C:" -RecoveryPasswordProtector rồi sao lưu lại — làm ngay hôm nay, đừng để mai. Còn nếu máy đã rơi vào màn hình đòi khoá 48 số mà không ai có khoá, thì đúng là mất vĩnh viễn dữ liệu trên ổ đó: không có cửa sau, không có công cụ khôi phục, Microsoft cũng không mở hộ được.

TLS 1.3 có tương thích ngược với client cũ không? Có — Schannel tự thương lượng xuống TLS 1.2 nếu client chưa hỗ trợ TLS 1.3.

SMB Encryption có thay được VPN không? Không — hai lớp bảo vệ hai phạm vi khác nhau, nên dùng cả hai với dữ liệu nhạy cảm.

Doanh nghiệp nhỏ không có SQL Server thì có cần đọc mục TDE/Always Encrypted không? Không bắt buộc — tập trung BitLocker + TLS 1.3 + SMB Encryption là đủ cho phần mã hoá, bỏ qua Bước 8. Nhưng phần sao lưu, quản lý tài khoản và nhật ký ở cuối Checklist thì vẫn phải làm, không phụ thuộc có SQL Server hay không.

Vì sao một số bước không có lệnh PowerShell mà phải vào tận BIOS/UEFI? Vì đó là cấu hình firmware, ngoài quyền kiểm soát của hệ điều hành đang chạy — chủ đích thiết kế bảo mật.

STEP có thể hỗ trợ gì

Nếu công ty đang cân nhắc chuyển máy chủ Windows Server 2022 lên hạ tầng cloud thay vì tự vận hành phần cứng, Public Cloud và Private Cloud của STEP đều hỗ trợ cài Windows Server (license tính thêm) trên nền ảo hoá KVM, đặt tại datacenter trong nước. Nói cho chính xác: Luật Bảo vệ dữ liệu cá nhân 91/2025 không bắt buộc dữ liệu cá nhân phải nằm tại Việt Nam, nên riêng việc đặt máy trong nước tự nó chưa phải là bằng chứng tuân thủ. Cái nó giúp là không phát sinh nghĩa vụ lập hồ sơ đánh giá tác động chuyển dữ liệu cá nhân xuyên biên giới — nhóm hành vi có khung phạt nặng nhất trong lĩnh vực này, tính theo phần trăm doanh thu chứ không theo mức cố định. Ngoài ra, nếu doanh nghiệp của bạn thuộc diện Luật An ninh mạng số 116/2025/QH15 (doanh nghiệp trong nước hoặc nước ngoài cung cấp dịch vụ trên mạng viễn thông, Internet, dịch vụ gia tăng trên không gian mạng tại Việt Nam có xử lý dữ liệu người dùng), thì lưu trữ dữ liệu tại Việt Nam là nghĩa vụ bắt buộc kể từ 01/7/2026.

Về license Windows Server, STEP tư vấn đúng kênh theo từng tình huống:

• Chưa có license, muốn tính gọn theo tháng: STEP cấp license theo SPLA (Services Provider License Agreement), tính theo tháng và gộp thẳng vào hoá đơn dịch vụ.
• Đã có license, muốn mang sang dùng: license mua dạng thuê bao (subscription) qua CSP đã có quyền License Mobility từ 01/04/2026, nên chạy được trên hạ tầng của nhà cung cấp dịch vụ. License Volume có Software Assurance cũng vậy. Ngược lại, license CSP mua đứt (perpetual) thì KHÔNG mang sang được.
• License OEM/ROK mua kèm máy chủ: loại này gắn chết với đúng cái máy vật lý được bán kèm, không chuyển lên cloud dùng chung được.
• Lợi thế riêng của Private Cloud STEP: với phần cứng dùng riêng cho một khách, STEP ở vai trò nhà thầu hạ tầng được uỷ quyền (Authorized Outsourcer) theo Microsoft Product Terms — khách vẫn được triển khai license on-prem của mình trên phần cứng đó.

Máy ảo tại STEP hỗ trợ tới đâu cho các bước trong bài này — nói rõ để bạn biết trước, không phải dựng xong mới phát hiện thiếu:

Điểm quan trọng nhất: hãy nêu nhu cầu bật vTPM và VBS ngay lúc đặt dịch vụ, đừng để dựng máy xong mới yêu cầu — làm từ đầu đơn giản hơn nhiều so với làm sau khi máy đã chạy dữ liệu thật.

Với gói Private Cloud (phần cứng dùng riêng cho một khách), cả ba tính năng trên được bật ngay từ khi dựng máy.

Nguồn tham khảo

• TLS Cipher Suites in Windows Server 2022 — Microsoft Learn
• Manage Transport Layer Security (TLS) in Windows Server — Microsoft Learn
• Enable-TlsCipherSuite (TLS module) — Microsoft Learn
• SMB Security Enhancements — Microsoft Learn
• BitLocker Overview / Configure BitLocker / BitLocker FAQ / BitLocker recovery overview — Microsoft Learn
• Confirm-SecureBootUEFI (SecureBoot module) — Microsoft Learn
• Transparent Data Encryption (TDE) / SQL Server Encryption overview / Configure TLS 1.3 on SQL Server 2022 — Microsoft Learn
• Install the SQL Server PowerShell module — Microsoft Learn
• Credential Guard overview / Configure Credential Guard — Microsoft Learn
• Set-MpPreference (Defender module) — Microsoft Learn
• Tamper protection overview — Microsoft Defender for Endpoint, Microsoft Learn
• New-NetFirewallRule / Disable-NetFirewallRule (NetSecurity module) — Microsoft Learn
• What's New in Windows Server 2022 — Microsoft Learn
• How to use Windows Server 2022 secured-core server features — TechTarget
• Network security gets a boost in Windows Server 2022 — TechTarget
• Luật Bảo vệ dữ liệu cá nhân số 91/2025/QH15 — Công báo Chính phủ
• Nghị định 356/2025/NĐ-CP (hướng dẫn Luật 91/2025) — Cổng thông tin văn bản Chính phủ
• Nghị định 330/2026/NĐ-CP (xử phạt vi phạm bảo vệ dữ liệu cá nhân và an ninh mạng) — Cổng thông tin văn bản Chính phủ
• Luật An ninh mạng số 116/2025/QH15 — Công báo Chính phủ