Vietnamese Professional - CCIE Security

Vietnamese Professional - CCIE Security https://www.forum.vnpro.org/ Dành cho các thảo luận Cisco Certified Internetwork Expert Security vi Thu, 23 Apr 2026 04:06:45 GMT vBulletin 60 images/misc/rss.png Vietnamese Professional - CCIE Security https://www.forum.vnpro.org/ Xác thực thiết bị https://www.forum.vnpro.org/forum/ccie®/ccie-security/439706-xác-thực-thiết-bị Wed, 22 Apr 2026 10:18:13 GMT Xác thực và Ủy quyền trên một thiết bị riêng biệt – Một mô hình bảo vệ danh tính rất đáng chú ý Trong các ứng dụng hiện đại, đặc biệt trên thiết... Xác thực và Ủy quyền trên một thiết bị riêng biệt – Một mô hình bảo vệ danh tính rất đáng chú ý

Trong các ứng dụng hiện đại, đặc biệt trên thiết bị di động và môi trường BYOD (Bring Your Own Device), câu hỏi lớn không còn là làm sao bắt người dùng đăng nhập, mà là:

Làm sao xác thực người dùng mà không làm lộ thông tin đăng nhập của họ?

Đây chính là ý tưởng mà slide này đang nói đến: Authentication/Authorization in a Separate Device. Bài toán của xác thực trên thiết bị di động

Khi người dùng cài một ứng dụng trên điện thoại cá nhân, thiết bị đó thường:

Không do doanh nghiệp quản lý hoàn toàn
Có thể chứa ứng dụng độc hại (rogue apps)
Có nguy cơ bị malware đánh cắp credentials
Có thể không đáng tin để nhập username/password trực tiếp

Nếu ứng dụng yêu cầu người dùng nhập tài khoản doanh nghiệp ngay trên thiết bị đó, thông tin định danh (credentials) có thể trở thành mục tiêu tấn công.

Đây là một rủi ro lớn trong Zero Trust và Identity Security.

Giải pháp thú vị: "Không xác thực trên thiết bị đó"

Nghe nghịch lý nhưng lại rất hay:

Thay vì xác thực trên thiết bị đang dùng ứng dụng, ta xác thực trên một thiết bị khác đáng tin cậy hơn.

Slide nói vui:

"The right approach might be… not to do authentication at all."

Ý không phải bỏ xác thực, mà là:

Ứng dụng không trực tiếp xử lý password
Thiết bị chỉ làm vai trò “requesting device”
Xác thực diễn ra trên một thiết bị khác hoặc kênh khác

Đây là tư tưởng của Device Authorization Flow.

Device Authorization – RFC 8628

Chuẩn này được định nghĩa trong RFC 8628 và là một phần mở rộng của OAuth 2.0.

Nó được thiết kế cho:

Smart TV
IoT devices
CLI tools
Mobile onboarding
Các thiết bị khó hoặc không nên nhập mật khẩu

Cách hoạt động

Thay vì login trực tiếp: Bước 1

Thiết bị hiển thị:

QR code
hoặc
Device code + URL

Ví dụ:

https://login.microsoftonline.com/device

Code:

ABCD-1234

Bước 2

Người dùng dùng điện thoại hoặc laptop đáng tin cậy hơn:

Quét QR
Đăng nhập trên trình duyệt bảo mật
Hoàn tất MFA

Bước 3

Authorization server cấp token cho thiết bị ban đầu.

Thiết bị chưa từng thấy password.

Rất đẹp.

Ví dụ thực tế: Sign in with QR code

Trong hình Webex có tùy chọn:

Sign in with QR code

Đây chính là cùng triết lý này.

Ứng dụng trên mobile được liên kết với user account thông qua:

QR pairing
Token exchange
Device binding

Không cần gõ credentials trên app.

Vì sao mô hình này an toàn hơn?

1. Giảm rủi ro lộ mật khẩu

App không xử lý password.

Credential theft khó xảy ra hơn.

2. Chống rogue applications

Nếu ứng dụng bị giả mạo:

Nó không lấy được password
Chỉ nhận được token giới hạn

3. Tận dụng MFA mạnh

Authentication có thể diễn ra trên thiết bị đã có:

FIDO2 key
Biometrics
Authenticator App
Conditional Access

4. Phù hợp Zero Trust

Tin cậy không đặt ở thiết bị yêu cầu truy cập.

Tin cậy đặt ở:

Identity Provider (IdP)
Token
Device posture
Policy engine

Đây chính là Zero Trust thinking.

Azure / Microsoft Entra ID liên quan thế nào?

Microsoft Entra ID (Azure AD trước đây) dùng tư tưởng tương tự trong:

Device Code Flow
Passwordless authentication
Microsoft Authenticator approval
Temporary Access Pass
FIDO2 sign-in

Ví dụ CLI:
az login --use-device-code

CLI trả mã.

Bạn mở trình duyệt xác thực.

Đó là RFC 8628.

Đây không chỉ là tiện lợi, mà là kiến trúc bảo mật

Nhiều người nghĩ QR login chỉ để tiện.

Thực ra đây là:

Security architecture pattern
Identity protection mechanism
Credential exposure reduction model

Đó là lý do nó xuất hiện nhiều trong:

Cisco Webex
Microsoft
Google
AWS console workflows
Modern passwordless systems

Góc nhìn thực chiến

Nếu thiết kế hệ thống IAM hiện đại, nên cân nhắc:

Không bắt app mobile xử lý credentials nếu không cần
Ưu tiên OAuth Device Flow cho unmanaged devices
Kết hợp Conditional Access + Device Compliance
Dùng QR/device authorization cho BYOD onboarding

Đây là nơi usability và security gặp nhau.

Kết luận

Đôi khi cách tốt nhất để bảo vệ thông tin xác thực là đừng để ứng dụng chạm vào thông tin xác thực ngay từ đầu.

Authentication diễn ra ở nơi tin cậy hơn.

Thiết bị chỉ được ủy quyền (authorized), không giữ bí mật của người dùng.

Đó là tư duy của Identity Security hiện đại.
]]> CCIE Security dangquangminh https://www.forum.vnpro.org/forum/ccie®/ccie-security/439706-xác-thực-thiết-bị Tcpip https://www.forum.vnpro.org/forum/ccie®/ccie-security/439506-tcpip Sat, 11 Apr 2026 11:34:22 GMT TCP/IP – Từ dự án quân sự đến nền tảng của Internet toàn cầu Khi học về mạng, nhiều người thường nghĩ TCP/IP là một chuẩn hoàn chỉnh, được thiết... TCP/IP – Từ dự án quân sự đến nền tảng của Internet toàn cầu

Khi học về mạng, nhiều người thường nghĩ TCP/IP là một chuẩn hoàn chỉnh, được thiết kế bài bản ngay từ đầu. Nhưng thực tế lại hoàn toàn ngược lại.

TCP/IP được xây dựng theo kiểu “evolutionary design” – phát triển dần theo nhu cầu thực tế.

Ban đầu, nó chỉ phục vụ cho ARPAnet – một mạng nghiên cứu của Bộ Quốc phòng Mỹ với vài trăm thiết bị. Mục tiêu lúc đó không phải là Internet như ngày nay, mà chỉ là:

Chia sẻ tài nguyên (file, ứng dụng)
Tăng khả năng cộng tác giữa các nhà nghiên cứu
Đảm bảo hệ thống vẫn hoạt động ngay cả khi một phần mạng bị phá hủy (yếu tố quân sự)

Chính những yêu cầu thực tế này đã định hình nên TCP/IP.

Vì sao TCP/IP trở thành “chuẩn thống trị”?

Có rất nhiều giao thức mạng từng tồn tại: IPX/SPX, AppleTalk, NetBEUI… nhưng tất cả đều dần biến mất. TCP/IP thì không.

Lý do:

Khả năng định tuyến (Routable)
TCP/IP cho phép giao tiếp xuyên mạng, từ LAN → WAN → Internet. Đây là yếu tố sống còn.
Thiết kế mở (Open Standard)
Không bị khóa bởi vendor nào → ai cũng có thể triển khai.
Khả năng mở rộng (Scalability)
Từ vài trăm node → hàng tỷ thiết bị hiện nay.
Khả năng tích hợp
Dễ dàng tích hợp với các giao thức khác và công nghệ mới như Cloud, IoT, AI.

Nhìn TCP/IP dưới góc độ Cloud & System

Nếu bạn đang làm Azure, AWS hay System Admin, hãy nhìn TCP/IP như sau:

TCP/IP chính là “ngôn ngữ chung” của toàn bộ Cloud
Mọi dịch vụ: VM, Kubernetes, Load Balancer, VPN… đều chạy trên TCP/IP
Không hiểu TCP/IP → không thể troubleshoot Cloud

Ví dụ thực tế:

SSH (port 22) → quản trị Linux VM trên Azure/AWS
RDP (port 3389) → truy cập Windows Server
DNS → phân giải domain trong VNet / VPC
IPsec → Site-to-Site VPN giữa on-prem và cloud

Các nhóm giao thức quan trọng trong TCP/IP

Khi học, nên chia theo nhóm để dễ hiểu:

Application Layer (tầng ứng dụng)
Đây là nơi bạn tương tác hàng ngày:

SSH, Telnet → remote access
DNS → phân giải tên
SNMP → monitoring
SMB → chia sẻ file

Security Protocols
Rất quan trọng trong môi trường hiện đại:

TLS/SSL → mã hóa dữ liệu
IPsec → VPN
AH/ESP → bảo mật ở Layer 3

Remote Access

RDP → quản trị Windows
SIP → VoIP

Database

SQL Server, MySQL → ứng dụng backend

Góc nhìn thực chiến

Một sai lầm phổ biến của người mới:

“Học TCP/IP chỉ để thi”

Thực tế:

90% lỗi hệ thống đều liên quan đến network
80% troubleshooting Cloud quay về TCP/IP

Ví dụ:

Không SSH được → kiểm tra port, firewall, routing
Web không load → DNS hay TCP timeout
VPN không lên → IPsec phase 1/2

Kết luận

TCP/IP không phải là một lý thuyết khô khan. Nó là nền tảng của:

Internet
Cloud (Azure, AWS, GCP)
System & Security

Nếu bạn muốn đi xa trong ngành IT:

Hiểu TCP/IP không chỉ là lợi thế — mà là điều bắt buộc.
]]> CCIE Security dangquangminh https://www.forum.vnpro.org/forum/ccie®/ccie-security/439506-tcpip