NIST.SP.800-190 - tiếng việt

Machine Translated by Google
Ấn phẩm đặc biệt của NIST 800-190
Hướng dẫn bảo mật vùng chứa ứng dụng
Súp Murugiah
John Morello
Karen Scarfone
Ấn bản này được cung cấp miễn phí tại: https://

doi.org/10.6028/NIST.SP.800-190
BẢO MẬT MÁY TÍNH

Ấn phẩm đặc biệt của NIST 800-190
Hướng dẫn bảo mật vùng chứa ứng dụng
Súp Murugiah
Phòng An ninh Máy tính
Phòng thí nghiệm công nghệ thông tin
John Morello
khóa xoắn
Baton Rouge, Louisiana
Karen Scarfone
An ninh mạng Scarfone

Clifton, Virginia
Ấn bản này được cung cấp miễn phí tại: https://

doi.org/10.6028/NIST.SP.800-190
tháng 9 năm 2017
Bộ Thương mại Hoa Kỳ Wilbur

L. Ross, Jr., Bộ trưởng
Viện Tiêu chuẩn và Công nghệ

Kent Rochford, Quyền Thứ trưởng Bộ Thương mại về Tiêu chuẩn và Công nghệ và Quyền Giám đốc
đ
n
bt
p
cm NIST SP 800-190
Thẩm quyền
HƯỚNG DẪN BẢO MẬT CONTAINER ỨNG DỤNG
Ấn phẩm này được NIST phát triển theo trách nhiệm pháp lý của NIST theo Đạo luật hiện đại hóa an ninh thông
tin liên bang (FISMA) năm 2014, 44 USC § 3551 et seq., Luật công
(PL) 113-283. NIST chịu trách nhiệm phát triển các tiêu chuẩn và hướng dẫn bảo mật thông tin, bao gồm
các yêu cầu tối thiểu đối với hệ thống thông tin liên bang, nhưng các tiêu chuẩn và hướng dẫn đó sẽ không áp
Ấ
dụng cho các hệ thống an ninh quốc gia nếu không có sự chấp thuận rõ ràng của các quan chức liên bang
thích hợp có thẩm quyền về chính sách đối với các hệ thống đó. Hướng dẫn này phù hợp với yêu cầu của Thông
tư A-130 của Văn phòng Quản lý và Ngân sách (OMB).
Không có nội dung nào trong ấn phẩm này được coi là mâu thuẫn với các tiêu chuẩn và hướng dẫn do Bộ trưởng
Bộ Thương mại đưa ra bắt buộc và ràng buộc đối với các cơ quan liên bang theo thẩm quyền theo luật định.
Những hướng dẫn này cũng không được hiểu là thay đổi hoặc thay thế các thẩm quyền hiện có của Bộ trưởng
Thương mại, Giám đốc OMB hoặc bất kỳ quan chức liên bang nào khác. Ấn phẩm này có thể được các tổ
chức phi chính phủ sử dụng trên cơ sở tự nguyện và không tuân theo bản quyền ở Hoa Kỳ.
Tuy nhiên, sự ghi công sẽ được NIST đánh giá cao.
Viện Tiêu chuẩn và Công nghệ Quốc gia Ấn bản đặc biệt 800-190
Natl. Inst. Đứng. Technol. Thông số kỹ thuật. Công bố 800-190, 63 trang (tháng 9/2017)
MÃ: NSPUE2
Ấn phẩm này được cung cấp miễn phí tại:

https://doi.org/10.6028/NIST.SP.800-190
Một số thực thể thương mại, thiết bị hoặc vật liệu nhất định có thể được xác định trong tài liệu này để mô tả
đầy đủ quy trình hoặc khái niệm thử nghiệm. Việc nhận dạng như vậy không nhằm mục đích hàm ý khuyến nghị hoặc
chứng thực của NIST, cũng không nhằm ngụ ý rằng các thực thể, vật liệu hoặc thiết bị nhất thiết phải là loại tốt
nhất sẵn có cho mục đích này.
Trong ấn phẩm này có thể có các tài liệu tham khảo đến các ấn phẩm khác hiện đang được NIST phát triển theo
trách nhiệm pháp lý được giao. Thông tin trong ấn phẩm này, bao gồm các khái niệm và phương pháp, có thể được các cơ
quan liên bang sử dụng ngay cả trước khi hoàn thành các ấn phẩm đồng hành đó. Do đó, cho đến khi mỗi ấn phẩm được
hoàn thành, các yêu cầu, hướng dẫn và thủ tục hiện hành, nếu có, vẫn có hiệu lực. Vì mục đích lập kế hoạch và
chuyển đổi, các cơ quan liên bang có thể muốn theo dõi chặt chẽ sự phát triển của các ấn phẩm mới này của NIST.
Các tổ chức được khuyến khích xem xét tất cả các ấn phẩm dự thảo trong thời gian lấy ý kiến công chúng và cung cấp
phản hồi cho NIST. Nhiều ấn phẩm về an ninh mạng của NIST, ngoài những ấn phẩm nêu trên, có sẵn tại
https://csrc.nist.gov/publications.
Ý kiến về ấn phẩm này có thể được gửi tới:
Viện Tiêu chuẩn và Công nghệ

Người nhận: Phòng An ninh máy tính, Phòng thí nghiệm Công nghệ thông tin
100 Bureau Drive (Mail Stop 8930) Gaithersburg, MD 20899-8930
Email: 800-190comments@nist.gov
Tất cả các bình luận đều có thể được tiết lộ theo Đạo luật Tự do Thông tin (FOIA).
Tôi
đ
n
b
Ất
p
cm NIST SP 800-190
Báo cáo Công nghệ hệ thống máy tính

Phòng thí nghiệm Công nghệ Thông tin (ITL) tại Viện Tiêu chuẩn và Công nghệ Quốc gia (NIST)
thúc đẩy nền kinh tế và phúc lợi công cộng Hoa Kỳ bằng cách cung cấp sự lãnh đạo kỹ thuật cho
cơ sở hạ tầng đo lường và tiêu chuẩn của Quốc gia. ITL phát triển các thử nghiệm, phương pháp thử
nghiệm, dữ liệu tham khảo, bằng chứng triển khai khái niệm và phân tích kỹ thuật để thúc đẩy sự
phát triển và sử dụng hiệu quả công nghệ thông tin. Trách nhiệm của ITL bao gồm phát triển các tiêu
chuẩn và hướng dẫn về quản lý, hành chính, kỹ thuật và vật lý để đảm bảo an ninh và quyền riêng tư
hiệu quả về mặt chi phí của các thông tin khác ngoài thông tin liên quan đến an ninh quốc gia
trong hệ thống thông tin liên bang. Ấn bản đặc biệt 800 báo cáo về nghiên cứu, hướng dẫn và nỗ
lực tiếp cận của ITL trong lĩnh vực bảo mật hệ thống thông tin cũng như các hoạt động hợp tác của
ITL với các tổ chức công nghiệp, chính phủ và học thuật.
trừu tượng
Công nghệ container ứng dụng hay còn gọi là container là một hình thức ảo hóa hệ điều hành kết
hợp với việc đóng gói phần mềm ứng dụng. Các thùng chứa cung cấp một cách di động, có thể tái sử
dụng và tự động hóa để đóng gói và chạy các ứng dụng. Ấn phẩm này giải thích những mối lo ngại về
bảo mật tiềm ẩn liên quan đến việc sử dụng thùng chứa và đưa ra các khuyến nghị để giải quyết những
mối lo ngại này.
Từ khóa
ứng dụng; thùng chứa ứng dụng; đóng gói phần mềm ứng dụng; thùng đựng hàng; an ninh container; sự
cách ly; ảo hóa hệ điều hành; ảo hóa
ii
đ
n
bt
p
cm NIST SP 800-190
Sự nhìn nhận
Các tác giả muốn cảm ơn các đồng nghiệp của họ đã xem xét bản thảo của tài liệu này và
đóng góp vào nội dung kỹ thuật của tài liệu trong quá trình phát triển, đặc biệt là Raghuram
Yeluri từ Tập đoàn Intel, Paul Cichonski từ Cisco Systems, Inc., Michael Bartock và
Jeffrey Cichonski từ NIST, và Edward Siewick. Các tác giả cũng thừa nhận các tổ chức
Ấ
đã cung cấp phản hồi trong thời gian lấy ý kiến công chúng, bao gồm Docker, Motorola
Solutions, StackRox, Cơ quan Di trú và Nhập tịch Hoa Kỳ (USCIS) và Quân đội Hoa Kỳ.
Khán giả
Đối tượng mục tiêu của tài liệu này là quản trị viên hệ thống và bảo mật, người quản lý chương
trình bảo mật, nhân viên bảo mật hệ thống thông tin, nhà phát triển ứng dụng và những người
khác có trách nhiệm hoặc quan tâm đến bảo mật của công nghệ bộ chứa ứng dụng.
Tài liệu này giả định rằng người đọc có kiến thức chuyên môn về hệ điều hành, mạng và bảo
mật cũng như kiến thức chuyên môn về công nghệ ảo hóa (trình ảo hóa và máy ảo). Do
tính chất thay đổi liên tục của các công nghệ vùng chứa ứng dụng, người đọc được khuyến
khích tận dụng các nguồn tài nguyên khác, bao gồm cả những tài nguyên được liệt kê trong
tài liệu này, để có thêm thông tin chi tiết và cập nhật.
Thông tin nhãn hiệu
Tất cả các nhãn hiệu hoặc nhãn hiệu đã đăng ký đều thuộc về các tổ chức tương ứng của họ.
iii
đ
n
b
Ất
p
cm NIST SP 800-190
Tóm tắt điều hành

Ảo hóa hệ điều hành (OS) cung cấp chế độ xem ảo hóa riêng biệt của HĐH cho từng ứng dụng, do đó giữ
cho mỗi ứng dụng được tách biệt khỏi tất cả các ứng dụng khác trên máy chủ. Mỗi ứng dụng chỉ có
thể nhìn thấy và ảnh hưởng đến chính nó. Gần đây, ảo hóa hệ điều hành ngày càng trở nên phổ biến nhờ
những tiến bộ về tính dễ sử dụng và sự tập trung nhiều hơn vào tính linh hoạt của nhà phát triển như
một lợi ích chính. Các công nghệ ảo hóa hệ điều hành ngày nay chủ yếu tập trung vào việc cung cấp một
phương thức di động, có thể tái sử dụng và tự động hóa để đóng gói và chạy các ứng dụng (ứng dụng). Các
thuật ngữ vùng chứa ứng dụng hay đơn giản là vùng chứa thường được sử dụng để chỉ các công nghệ này.
Mục đích của tài liệu là giải thích các mối lo ngại về bảo mật liên quan đến công nghệ
vùng chứa và đưa ra các khuyến nghị thiết thực để giải quyết những mối lo ngại đó khi lập kế
hoạch, triển khai và bảo trì vùng chứa. Nhiều đề xuất dành riêng cho một thành phần hoặc tầng
cụ thể trong kiến trúc công nghệ vùng chứa, được mô tả trong
Hình 1.
Hình 1: Các tầng và thành phần kiến trúc công nghệ container
Các tổ chức nên tuân theo các khuyến nghị sau để giúp đảm bảo tính bảo mật cho việc triển khai và
sử dụng công nghệ vùng chứa của mình:
Điều chỉnh văn hóa hoạt động và quy trình kỹ thuật của tổ chức để hỗ trợ cách thức mới để phát
triển, chạy và hỗ trợ các ứng dụng được thực hiện bằng container.
Việc giới thiệu các công nghệ container có thể phá vỡ các phương pháp phát triển phần mềm
và văn hóa hiện có trong tổ chức. Các phương pháp phát triển truyền thống, kỹ thuật vá lỗi và quy
trình nâng cấp hệ thống có thể không áp dụng trực tiếp vào môi trường được chứa trong
container và điều quan trọng là nhân viên phải sẵn sàng thích ứng với mô hình mới. Nhân viên nên
được khuyến khích áp dụng các phương pháp được khuyến nghị để xây dựng và vận hành ứng dụng
trong vùng chứa một cách an toàn, như được đề cập trong hướng dẫn này, đồng thời tổ chức nên
sẵn sàng suy nghĩ lại các quy trình hiện có để tận dụng lợi thế của vùng chứa. Giáo dục và đào
tạo bao gồm cả công nghệ và phương pháp vận hành nên được cung cấp cho bất kỳ ai tham gia vào
vòng đời phát triển phần mềm.
iv
đ
n
b
Ất
p
cm NIST SP 800-190 HƯỚNG DẪN BẢO MẬT CONTAINER ỨNG DỤNG
Sử dụng hệ điều hành máy chủ dành riêng cho vùng chứa thay vì hệ điều hành có mục đích chung để giảm các bề mặt tấn công.
Hệ điều hành máy chủ dành riêng cho vùng chứa là một hệ điều hành tối giản được thiết kế rõ ràng để chỉ chạy các vùng
chứa, với tất cả các dịch vụ và chức năng khác bị vô hiệu hóa, đồng thời với các hệ thống tệp chỉ đọc và các biện pháp
tăng cường khác được sử dụng. Khi sử dụng hệ điều hành máy chủ dành riêng cho vùng chứa, các bề mặt tấn công thường nhỏ
hơn nhiều so với hệ điều hành máy chủ có mục đích chung, do đó sẽ có ít cơ hội hơn để tấn công và xâm phạm hệ điều hành
máy chủ dành riêng cho vùng chứa. Theo đó, bất cứ khi nào có thể, các tổ chức nên sử dụng hệ điều hành máy
chủ dành riêng cho vùng chứa để giảm thiểu rủi ro. Tuy nhiên, điều quan trọng cần lưu ý là các hệ điều hành
máy chủ dành riêng cho vùng chứa vẫn sẽ có các lỗ hổng theo thời gian cần được khắc phục.
Chỉ nhóm các vùng chứa có cùng mục đích, độ nhạy cảm và mức độ đe dọa trên một nhân hệ điều hành máy chủ duy nhất để
cho phép tăng cường phòng thủ theo chiều sâu.
Mặc dù hầu hết các nền tảng vùng chứa đều thực hiện công việc hiệu quả trong việc cách ly các vùng chứa với nhau và với
hệ điều hành máy chủ, nhưng việc chạy các ứng dụng có mức độ nhạy cảm khác nhau cùng nhau trên cùng một hệ điều
hành máy chủ có thể là một rủi ro không cần thiết. Phân đoạn vùng chứa theo mục đích, độ nhạy cảm và mức độ đe dọa
cung cấp thêm khả năng phòng thủ theo chiều sâu. Bằng cách nhóm các vùng chứa theo cách này, các tổ chức sẽ gây khó khăn
hơn cho kẻ tấn công xâm phạm một trong các nhóm để mở rộng sự xâm phạm đó sang các nhóm khác. Điều này làm tăng khả năng
phát hiện và ngăn chặn các hành vi xâm phạm, đồng thời đảm bảo rằng mọi dữ liệu còn sót lại, chẳng hạn như bộ đệm hoặc
ổ đĩa cục bộ được gắn cho tệp tạm thời, vẫn nằm trong vùng bảo mật của nó.
Trong môi trường quy mô lớn hơn với hàng trăm máy chủ và hàng nghìn container, việc nhóm này
phải được tự động hóa để có thể vận hành được trong thực tế. May mắn thay, công nghệ vùng chứa thường bao gồm một số khái
niệm về khả năng nhóm các ứng dụng lại với nhau và các công cụ bảo mật vùng chứa có thể sử dụng các thuộc tính như tên
và nhãn vùng chứa để thực thi các chính sách bảo mật trên chúng.
Áp dụng các công cụ và quy trình quản lý lỗ hổng dành riêng cho vùng chứa cho hình ảnh để ngăn chặn sự xâm phạm.
Các công cụ quản lý lỗ hổng truyền thống đưa ra nhiều giả định về độ bền của máy chủ và
các cơ chế và tần suất cập nhật ứng dụng về cơ bản không phù hợp với mô hình được chứa trong vùng chứa. Ví dụ: họ thường
cho rằng một máy chủ nhất định chạy một bộ ứng dụng nhất quán theo thời gian, nhưng các vùng chứa ứng dụng khác nhau
thực sự có thể chạy trên các máy chủ khác nhau vào bất kỳ thời điểm nào dựa trên tính khả dụng của tài nguyên. Hơn
nữa, các công cụ truyền thống thường không thể phát hiện các lỗ hổng trong vùng chứa, dẫn đến cảm giác an
toàn sai lầm. Các tổ chức nên sử dụng các công cụ áp dụng phương pháp xây dựng khai báo, từng bước cũng như tính
chất bất biến của vùng chứa và hình ảnh vào thiết kế của mình để mang lại kết quả đáng tin cậy và khả thi hơn.
Các công cụ và quy trình này phải tính đến cả lỗ hổng phần mềm hình ảnh và cài đặt cấu hình. Các tổ chức nên áp dụng
các công cụ và quy trình để xác thực và thực thi việc tuân thủ các biện pháp thực hành tốt nhất về cấu hình bảo mật
cho hình ảnh. Điều này phải bao gồm việc có báo cáo và giám sát tập trung về trạng thái tuân thủ của từng hình ảnh,
đồng thời ngăn chặn việc chạy các hình ảnh không tuân thủ.
v
đ
n
b
Ất
p
Hãy cân nhắc sử dụng các biện pháp đối phó dựa trên phần cứng để cung cấp cơ sở cho tính toán đáng tin cậy.
Bảo mật phải mở rộng trên tất cả các tầng của công nghệ container. Cách hiện tại để thực hiện
điều này là đặt cơ sở bảo mật dựa trên nền tảng tin cậy của phần cứng, chẳng hạn như Mô-đun nền tảng
đáng tin cậy (TPM) tiêu chuẩn ngành. Trong thư mục gốc của phần cứng tin cậy có các số đo được lưu trữ
về phần sụn, phần mềm và dữ liệu cấu hình của máy chủ. Việc xác thực các phép đo hiện tại dựa trên
các phép đo được lưu trữ trước khi khởi động máy chủ sẽ đảm bảo rằng máy chủ có thể được tin cậy. Chuỗi
tin cậy bắt nguồn từ phần cứng có thể được mở rộng sang nhân hệ điều hành và các thành phần hệ điều
hành để cho phép xác minh bằng mật mã các cơ chế khởi động, hình ảnh hệ thống, thời gian chạy vùng chứa
và hình ảnh vùng chứa. Điện toán đáng tin cậy cung cấp một cách an toàn để xây dựng, chạy, sắp
xếp và quản lý các vùng chứa.
Sử dụng các công cụ bảo vệ thời gian chạy nhận biết vùng chứa.
Triển khai và sử dụng giải pháp bảo mật vùng chứa chuyên dụng có khả năng ngăn chặn, phát hiện và ứng
phó với các mối đe dọa nhắm vào vùng chứa trong thời gian chạy. Các giải pháp bảo mật truyền thống, chẳng
hạn như hệ thống ngăn chặn xâm nhập (IPS) và tường lửa ứng dụng web (WAF), thường không cung cấp khả năng
bảo vệ phù hợp cho các container. Chúng có thể không hoạt động được ở quy mô vùng chứa, quản lý tốc
độ thay đổi trong môi trường vùng chứa và có khả năng hiển thị hoạt động của vùng chứa.
Sử dụng giải pháp bảo mật gốc vùng chứa có thể giám sát môi trường vùng chứa và cung cấp khả năng
phát hiện chính xác các hoạt động bất thường và độc hại trong đó.
vi
đ
n
b
Ất
p
cm NIST SP 800-190
Mục lục
Tóm tắt điều hành................................................................................. ................................................................. ... iv
1. Giới thiệu ................................................ ................................................................. .......... 1
1.1 Mục đích và phạm vi .................................................................... ................................... 1
1.2 Cấu trúc tài liệu................................................................................. ................................... 1
2 Giới thiệu về bộ chứa ứng dụng.................................................................. ................... 3
2.1 Các khái niệm cơ bản về ảo hóa ứng dụng và bộ chứa.................. 3
2.2 Bộ chứa và hệ điều hành máy chủ.................................................. ............ 5
2.3 Kiến trúc công nghệ vùng chứa................................................................. .... 7 2.3.1 Tạo hình ảnh,
kiểm tra và công nhận........... ...................... 9 2.3.2 Lưu trữ và truy xuất hình
ảnh........... ................................... 9
2.3.3 Triển khai và quản lý container.................................................................. 10
2.4 Công dụng của thùng chứa .................................................... ................................... 11
3 rủi ro chính đối với các thành phần cốt lõi của công nghệ container ................. 13
3.1 Rủi ro về hình ảnh ................................................................. ...............................................................
13 3.1.1 Lỗ hổng hình ảnh.................................................. ................... 13
3.1.2 Lỗi cấu hình hình ảnh ................................................................. ................... 13
3.1.3 Phần mềm độc hại nhúng.................................................................. ...................... 14
3.1.4 Bí mật văn bản rõ ràng được nhúng .................................... ................... 14
3.1.5 Sử dụng hình ảnh không đáng tin cậy.................................................. .................... 14
3.2 Rủi ro đăng ký........... ................................................................. ................... 14
3.2.1 Kết nối không an toàn tới các cơ quan đăng ký .................................................... .......... 14
3.2.2 Hình ảnh cũ trong sổ đăng ký.................................................. ................... 14
3.2.3 Hạn chế xác thực và ủy quyền không đầy đủ .................... 14
3.3 Rủi ro của người điều phối .................................................... ................................... 15
3.3.1 Truy cập quản trị không giới hạn.................................................. .......... 15
3.3.2 Truy cập trái phép.................................................................. ...................... 15
3.3.3 Lưu lượng mạng liên container bị phân tách kém .................... 15
3.3.4 Trộn các mức độ nhạy cảm của khối lượng công việc .................................... ............ 16
3.3.5 Sự tin cậy của nút soạn thảo.................................................. ...................... 16
3.4 Rủi ro về container .................................................................... ................................... 16
3.4.1 Các lỗ hổng trong phần mềm thời gian chạy.................................................. 16
vii
đ
n
bt
p
3.4.2 Truy cập mạng không giới hạn từ container................................................. 16
3.4.3 Cấu hình thời gian chạy vùng chứa không an toàn.................................. 17
3.4.4 Lỗ hổng ứng dụng ................................................................. ................................. 17
3.4.5 Thùng chứa giả mạo ................................................................. ................................... 17

Ấ
3.5 Rủi ro hệ điều hành máy chủ .................................................... ................................... 17
3.5.1 Bề mặt tấn công lớn................................................................. ................................. 17
3.5.2 Hạt nhân dùng chung ................................................................. ................................... 18
3.5.3 Các lỗ hổng thành phần hệ điều hành máy chủ .................................................... ............ 18
3.5.4 Quyền truy cập của người dùng không đúng .................................................... .................... 18 3.5.5
Giả mạo hệ thống tập tin hệ điều hành máy chủ ....... ......................................18 4 Biện pháp đối phó với các rủi ro
lớn...... ................................................................. ............ 19 4.1 Biện pháp đối phó với hình
ảnh .................... ................................... 19
4.1.1 Lỗ hổng hình ảnh.................................................................. ................... 19
4.1.2 Lỗi cấu hình hình ảnh ................................................................. ................... 19
4.1.3 Phần mềm độc hại nhúng.................................................................. ................... 20
4.1.4 Bí mật văn bản rõ ràng được nhúng .................................... ................... 20
4.1.5 Sử dụng hình ảnh không đáng tin cậy.................................................. ................... 20
4.2 Các biện pháp đối phó với đăng ký .................................................... ................... 21
4.2.1 Kết nối không an toàn tới các cơ quan đăng ký .................................................... .......... 21
4.2.2 Hình ảnh cũ trong sổ đăng ký.................................................. ................... 21
4.2.3 Hạn chế xác thực và ủy quyền không đầy đủ .... 21
4.3 Các biện pháp đối phó của người điều phối .................................................... ...................... 22
4.3.1 Truy cập quản trị không giới hạn.................................................. .......... 22
4.3.2 Truy cập trái phép.................................................................. ...................... 22
4.3.3 Lưu lượng mạng liên vùng bị phân tách kém .................... 22 4.3.4 Khối lượng công việc trộn lẫn mức độ nhạy
cảm................................................................................. ... 23
4.3.5 Sự tin cậy của nút soạn thảo.................................................. ...................... 24
4.4 Biện pháp đối phó với container................................................................. ................... 24
4.4.1 Các lỗ hổng trong phần mềm thời gian chạy.................................................. 24
4.4.2 Truy cập mạng không giới hạn từ container....................................... 24
4.4.3 Cấu hình thời gian chạy vùng chứa không an toàn.................................. 25 4.4.4 Lỗ hổng ứng
dụng................................................................. ................................. 25
viiii
đ
n
b
Ất
p
4.4.5 Thùng chứa giả mạo ................................................................. ................................... 26
4.5 Biện pháp đối phó với hệ điều hành máy chủ.................................................. ...................... 26
4.5.1 Bề mặt tấn công lớn................................................................. ...................... 26
4.5.2 Hạt nhân dùng chung ................................................................. ................................... 27
4.5.3 Các lỗ hổng thành phần hệ điều hành máy chủ ...................................................... .............
27 4.5.4 Quyền truy cập của người dùng không đúng .................... ...................... 27 4.5.5 Giả mạo hệ thống
tập tin máy chủ ............ ................................................................. ... 27
4.6 Biện pháp đối phó phần cứng.................................................................. ................... 28
5 Ví dụ về kịch bản mối đe dọa vùng chứa.................................................. .................... 30
5.1 Khai thác lỗ hổng trong hình ảnh.................................................. ............ 30 5.2 Khai thác thời gian
chạy container .................... ................................... 30
5.3 Chạy một hình ảnh bị nhiễm độc.................................................. ................... 30
6 Những điểm cần cân nhắc về an ninh vòng đời công nghệ container .................... 32
6.1 Giai đoạn khởi đầu .................................................................... ................................... 32
6.2 Giai đoạn lập kế hoạch và thiết kế.................................................. ...................... 32 6.3 Giai
đoạn thực hiện .................... ................................................................. ............ 33
6.4 Giai đoạn vận hành và bảo trì.................................................. ............ 34
6.5 Giai đoạn xử lý .................................................................... ................................... 35
7. Kết luận ................................................ ................................................................. ............ 36
Danh mục các phụ lục
Phụ lục A— Tài nguyên của NIST để bảo mật các thành phần không cốt lõi .... 38
Phụ lục B— Các biện pháp kiểm soát bảo mật của Khung an ninh mạng NIST SP 800-53 và NIST liên quan đến công nghệ vùng
chứa ...................... ...................... 39
Phụ lục C— Các từ viết tắt ................................................................. ............ 46 Phụ lục D— Bảng thuật
ngữ ................................. ................................................................. ............ 48 Phụ lục E— Tài
liệu tham khảo................................. ................................................................. .......... 50
Danh sách bảng và hình
Hình 1: Các tầng và thành phần kiến trúc công nghệ container..................iv Hình 2:
Triển khai máy ảo và container ... ................................... 5 Hình 3: Các tầng,
thành phần và giai đoạn vòng đời của kiến trúc công nghệ container8
Bảng 1: Tài nguyên NIST để bảo mật các thành phần không cốt lõi .................................... 38
ix
đ
n
b
Ất
p
cm NIST SP 800-190
Bảng 2: Kiểm soát bảo mật từ NIST SP 800-53 cho Bảo mật công nghệ container... 39
Bảng 3: Các biện pháp kiểm soát NIST SP 800-53 được hỗ trợ bởi công nghệ container........... 43
Bảng 4: Các danh mục con của Khung an ninh mạng NIST được Container hỗ trợ
Công nghệ................................................................. ................................................................. ....... 43
x
đ
n
b
Ất
p
cm NIST SP 800-190
1 Giới thiệu
1.1 Mục đích và phạm vi

Mục đích của tài liệu là giải thích các mối lo ngại về bảo mật liên quan đến công nghệ vùng chứa
ứng dụng và đưa ra các khuyến nghị thực tế để giải quyết những mối lo ngại đó khi lập kế hoạch, triển
khai và bảo trì vùng chứa. Một số khía cạnh của vùng chứa có thể khác nhau giữa các công nghệ, nhưng
các khuyến nghị trong tài liệu này nhằm mục đích áp dụng cho hầu hết hoặc tất cả các công nghệ vùng chứa
ứng dụng.
Tất cả các dạng ảo hóa ngoài vùng chứa ứng dụng, chẳng hạn như máy ảo, đều nằm ngoài phạm vi của
tài liệu này.
Ngoài các công nghệ bộ chứa ứng dụng, thuật ngữ “bộ chứa” còn được dùng để chỉ các khái niệm như phần
mềm tách biệt dữ liệu doanh nghiệp khỏi dữ liệu cá nhân trên thiết bị di động và phần mềm có thể được
sử dụng để cách ly các ứng dụng với nhau trên hệ điều hành máy tính để bàn. Mặc dù chúng có thể chia
sẻ một số thuộc tính với công nghệ bộ chứa ứng dụng nhưng chúng nằm ngoài phạm vi của tài liệu này.
Tài liệu này giả định người đọc đã quen với việc bảo mật các công nghệ hỗ trợ và tương tác với các
công nghệ bộ chứa ứng dụng. Chúng bao gồm những điều sau đây:
• Các lớp trong công nghệ bộ chứa ứng dụng, bao gồm phần cứng, bộ ảo hóa và hệ điều hành;
• Các công cụ quản trị sử dụng các ứng dụng trong vùng chứa; Và
• Điểm cuối của quản trị viên được sử dụng để quản lý các ứng dụng trong vùng chứa và chính các
vùng chứa đó.
Phụ lục A chứa các gợi ý tới các tài nguyên có thông tin về việc bảo mật các công nghệ này.
Phần 3 và 4 cung cấp thông tin bổ sung về các cân nhắc bảo mật cho các hệ điều hành dành riêng cho vùng
chứa. Tất cả các cuộc thảo luận sâu hơn về việc bảo mật các công nghệ được liệt kê ở trên đều nằm ngoài phạm
vi của tài liệu này.
1.2 Cấu trúc tài liệu
Phần còn lại của tài liệu này được tổ chức thành các phần và phụ lục sau:
• Phần 2 giới thiệu các container, bao gồm khả năng kỹ thuật, kiến trúc công nghệ và cách
sử dụng.
• Phần 3 giải thích các rủi ro chính đối với các thành phần cốt lõi của vùng chứa ứng dụng
công nghệ.
• Phần 4 khuyến nghị các biện pháp đối phó với các rủi ro được xác định ở Phần 3.
• Phần 5 xác định các ví dụ về kịch bản đe dọa đối với container.
• Phần 6 trình bày thông tin hữu ích cho việc lập kế hoạch, triển khai, vận hành và bảo trì
công nghệ container.
• Phần 7 đưa ra kết luận của tài liệu.
1
đ
n
b
Ất
p
• Phụ lục A liệt kê các tài nguyên NIST để bảo mật các thành phần không cốt lõi của vùng chứa
công nghệ.
• Phụ lục B liệt kê các biện pháp kiểm soát bảo mật trong Ấn bản đặc biệt 800-53 của NIST và NIST
Các danh mục con của Khung An ninh mạng phù hợp nhất với các công nghệ bộ chứa ứng dụng, giải thích
mức độ liên quan của từng danh mục.
• Phụ lục C cung cấp từ viết tắt và danh sách viết tắt cho tài liệu.
• Phụ lục D trình bày bảng chú giải các thuật ngữ được lựa chọn trong tài liệu.
• Phụ lục E chứa danh sách tài liệu tham khảo của tài liệu.
2
đ
n
b
Ất
p
cm NIST SP 800-190
2 Giới thiệu về Bộ chứa ứng dụng

Phần này giới thiệu về vùng chứa cho các ứng dụng máy chủ (ứng dụng). Đầu tiên, nó xác định các khái
niệm cơ bản về ảo hóa ứng dụng và các vùng chứa cần thiết để hiểu phần còn lại của tài liệu. Tiếp
theo, phần này giải thích cách các vùng chứa tương tác với hệ điều hành mà chúng chạy trên đó. Phần
tiếp theo của phần này minh họa kiến trúc tổng thể của công nghệ vùng chứa, xác định tất cả các
thành phần chính thường thấy trong quá trình triển khai vùng chứa
và giải thích quy trình công việc giữa các thành phần. Phần cuối cùng của phần mô tả
sử dụng phổ biến cho container.
2.1 Các khái niệm cơ bản về ảo hóa ứng dụng và bộ chứa
Ấn phẩm Đặc biệt của NIST (SP) 800-125 [1] định nghĩa ảo hóa là “sự mô phỏng của phần mềm và/
hoặc phần cứng mà phần mềm khác chạy trên đó”. Ảo hóa đã được sử dụng trong nhiều năm nhưng nó
được biết đến nhiều nhất nhờ khả năng hỗ trợ điện toán đám mây. Trong môi trường đám mây, phần cứng
ảo hóa được sử dụng để chạy nhiều phiên bản của hệ điều hành (HĐH) trên một máy chủ vật lý trong
khi vẫn tách biệt từng phiên bản. Điều này cho phép sử dụng phần cứng hiệu quả hơn và hỗ trợ
nhiều bên thuê.
Trong ảo hóa phần cứng, mỗi phiên bản hệ điều hành tương tác với phần cứng ảo hóa. Một dạng ảo hóa
khác được gọi là ảo hóa hệ điều hành cũng có khái niệm tương tự; nó cung cấp nhiều hệ điều
hành ảo hóa trên một nhân hệ điều hành thực tế. Cách tiếp cận này thường được gọi là bộ chứa hệ
điều hành và nhiều cách triển khai bộ chứa hệ điều hành khác nhau đã tồn tại từ đầu những năm
2000, bắt đầu với các nhà tù Solaris Zone và FreeBSD.1 Hỗ trợ ban đầu có sẵn trong Linux vào năm
2008 với công nghệ Linux Container (LXC) được tích hợp trong gần như tất cả các bản phân phối hiện
đại. Bộ chứa hệ điều hành khác với bộ chứa ứng dụng là chủ đề của hướng dẫn này vì bộ chứa hệ điều
hành được thiết kế để cung cấp một môi trường hoạt động giống như một hệ điều hành thông thường
trong đó nhiều ứng dụng và dịch vụ có thể cùng tồn tại.
Gần đây, ảo hóa ứng dụng ngày càng trở nên phổ biến nhờ những tiến bộ về tính dễ sử dụng và sự tập trung nhiều hơn vào
tính linh hoạt của nhà phát triển như một lợi ích chính. Trong ảo hóa ứng dụng, cùng một nhân hệ điều hành được chia sẻ
hầu như được hiển thị với nhiều ứng dụng riêng biệt. Các thành phần hệ điều hành giữ cho mỗi phiên bản ứng dụng được
tách biệt khỏi tất cả các phiên bản khác trên máy chủ. Trong trường hợp này, mỗi ứng dụng chỉ nhìn thấy hệ điều hành
và chính nó, đồng thời bị cô lập với các ứng dụng khác có thể đang chạy trên cùng nhân hệ điều hành này.
Sự khác biệt chính giữa ảo hóa hệ điều hành và ảo hóa ứng dụng là với ảo hóa ứng dụng, mỗi
phiên bản ảo thường chỉ chạy một ứng dụng duy nhất. Các công nghệ ảo hóa ứng dụng ngày nay
chủ yếu tập trung vào việc cung cấp giải pháp di động, có thể tái sử dụng và tự động hóa để đóng
gói và chạy ứng dụng. Các thuật ngữ chứa ứng dụng hay đơn giản là
container thường được sử dụng để chỉ những công nghệ này. Thuật ngữ này có ý nghĩa tương tự như các
container vận chuyển, cung cấp một cách tiêu chuẩn hóa để nhóm các nội dung khác nhau lại với nhau
trong khi cách ly chúng với nhau.
1
Để biết thêm thông tin về khái niệm nhà tù, hãy xem https://www.freebsd.org/doc/handbook/jails.html.
3
đ
n
b
Ất
p
Không giống như các kiến trúc ứng dụng truyền thống thường chia ứng dụng thành nhiều tầng (ví dụ: web, ứng dụng và cơ
sở dữ liệu) và có máy chủ hoặc VM cho mỗi tầng, kiến trúc vùng chứa thường có một ứng dụng được chia thành nhiều thành
phần hơn, mỗi thành phần có một chức năng được xác định rõ ràng và thường chạy trong (các) vùng chứa của chính nó.
Mỗi thành phần ứng dụng chạy trong một vùng chứa riêng biệt. Trong công nghệ vùng chứa ứng dụng, các tập hợp vùng chứa
hoạt động cùng nhau để tạo nên một ứng dụng được gọi là vi dịch vụ. Với phương pháp này, việc triển khai ứng dụng sẽ linh
hoạt và có thể mở rộng hơn. Việc phát triển cũng đơn giản hơn vì chức năng khép kín hơn. Tuy nhiên, có nhiều đối tượng
cần quản lý và bảo mật hơn, điều này có thể gây ra sự cố cho các công cụ bảo mật và quản lý ứng dụng
và các quá trình.
Hầu hết các công nghệ vùng chứa ứng dụng đều triển khai khái niệm về tính bất biến. Nói cách khác, bản thân các container
phải được vận hành như các thực thể không trạng thái được triển khai nhưng không thay đổi.2 Khi một container
đang chạy cần được nâng cấp hoặc thay đổi nội dung của nó, nó chỉ cần bị hủy và thay thế bằng một container mới có
các bản cập nhật. Điều này cho phép
các nhà phát triển và kỹ sư hỗ trợ thực hiện và thúc đẩy các thay đổi đối với ứng dụng với tốc độ nhanh hơn nhiều.
Các tổ chức có thể chuyển từ việc triển khai phiên bản ứng dụng mới hàng quý sang triển khai các thành phần mới hàng tuần
hoặc hàng ngày. Tính bất biến là điểm khác biệt cơ bản trong hoạt động giữa vùng chứa và ảo hóa phần cứng. Các máy
ảo truyền thống thường được chạy dưới dạng các thực thể có trạng thái được triển khai, cấu hình lại và nâng cấp trong
suốt vòng đời của chúng. Các công cụ và quy trình bảo mật cũ thường có phần lớn hoạt động tĩnh và có thể cần
được điều chỉnh để thích ứng với tốc độ thay đổi trong môi trường được chứa trong container.
Bản chất bất biến của vùng chứa cũng có ý nghĩa đối với sự tồn tại của dữ liệu. Thay vì trộn lẫn ứng dụng với dữ
liệu mà nó sử dụng, các bộ chứa nhấn mạnh khái niệm cô lập. Cần đạt được tính bền vững của dữ liệu không chỉ
bằng cách ghi đơn giản vào hệ thống tệp gốc của bộ chứa mà thay vào đó bằng cách sử dụng các kho lưu trữ dữ liệu liên
tục, bên ngoài như cơ sở dữ liệu hoặc khối lượng liên tục nhận biết cụm. Việc sử dụng vùng chứa dữ liệu phải được
lưu trữ bên ngoài vùng chứa để khi phiên bản tiếp theo của ứng dụng thay thế vùng chứa đang chạy phiên bản hiện có,
tất cả dữ liệu vẫn có sẵn cho phiên bản mới.
Các công nghệ vùng chứa hiện đại phần lớn đã xuất hiện cùng với việc áp dụng các phương pháp phát triển và vận hành
(DevOps) nhằm tìm cách tăng cường tích hợp giữa xây dựng và chạy ứng dụng, nhấn mạnh sự phối hợp chặt chẽ giữa các
nhóm phát triển và vận hành.3 Bản chất khai báo và di động của vùng chứa đặc biệt tốt phù hợp với những thực tiễn này vì
chúng cho phép tổ chức có được sự nhất quán cao giữa các môi trường phát triển, thử nghiệm và sản xuất. Các tổ chức thường
sử dụng các quy trình tích hợp liên tục để đưa ứng dụng của họ vào các vùng chứa trực tiếp trong chính quá trình xây
dựng, sao cho ngay từ đầu vòng đời của ứng dụng, môi trường thời gian chạy của ứng dụng đó đã được đảm bảo tính nhất
quán. Hình ảnh vùng chứa—
các gói chứa các tệp cần thiết để chạy vùng chứa—thường được thiết kế để có thể di động trên các máy và môi trường,
sao cho hình ảnh được tạo trong phòng thí nghiệm phát triển có thể dễ dàng được chuyển đến phòng thí nghiệm kiểm tra để
đánh giá, sau đó sao chép vào môi trường sản xuất để chạy mà không cần để thực hiện bất kỳ sửa đổi nào. Nhược điểm
của việc này là các công cụ và quy trình bảo mật
2
Lưu ý rằng mặc dù vùng chứa khiến tính bất biến trở nên thiết thực và thực tế nhưng chúng không yêu cầu điều đó, vì vậy các tổ chức cần điều
chỉnh phương thức hoạt động của mình để tận dụng lợi thế của nó.
3
Tài liệu này đề cập đến các nhiệm vụ được thực hiện bởi DevOps Persona. Việc đề cập đến những tính cách này tập trung vào các loại nhiệm vụ công
việc đang được thực hiện, chứ không phải vào các chức danh nghiêm ngặt hoặc cơ cấu tổ chức nhóm.
4
đ
n
b
Ất
p
được sử dụng để bảo vệ vùng chứa không được đưa ra giả định về các nhà cung cấp đám mây cụ thể, hệ điều hành máy
chủ, cấu trúc liên kết mạng hoặc các khía cạnh khác của môi trường thời gian chạy vùng chứa có thể thường xuyên
thay đổi. Quan trọng hơn nữa, tính bảo mật phải nhất quán trên tất cả các môi trường này và trong suốt vòng
đời ứng dụng từ quá trình phát triển, thử nghiệm đến sản xuất.
Gần đây, các dự án như Docker [2] và rkt [3] đã cung cấp chức năng bổ sung được thiết kế để giúp các tính năng
cách ly thành phần hệ điều hành dễ sử dụng và mở rộng quy mô hơn. Công nghệ vùng chứa cũng có sẵn trên nền tảng
Windows bắt đầu từ Windows Server 2016. Kiến trúc cơ bản của tất cả các triển khai này đủ nhất quán để tài
liệu này có thể thảo luận
container một cách chi tiết trong khi vẫn triển khai bất khả tri.
2.2 Bộ chứa và Hệ điều hành máy chủ
Việc giải thích việc triển khai ứng dụng trong vùng chứa được thực hiện dễ dàng hơn bằng cách so sánh nó với
việc triển khai ứng dụng trong máy ảo (VM) từ các công nghệ ảo hóa phần cứng mà nhiều độc giả đã quen thuộc.
Hình 2 cho thấy việc triển khai VM ở bên trái, một
triển khai vùng chứa không có máy ảo (được cài đặt trên “kim loại trần”) ở giữa và triển khai vùng chứa chạy
trong máy ảo ở bên phải.
Hình 2: Triển khai máy ảo và container
Cả VM và container đều cho phép nhiều ứng dụng chia sẻ cùng một cơ sở hạ tầng vật lý nhưng chúng sử dụng các
phương pháp phân tách khác nhau. Máy ảo sử dụng bộ ảo hóa cung cấp khả năng cách ly tài nguyên ở cấp độ phần cứng
trên các máy ảo. Mỗi VM nhìn thấy phần cứng ảo của riêng mình và bao gồm một hệ điều hành khách hoàn chỉnh bên
cạnh ứng dụng và dữ liệu của nó. Máy ảo cho phép các hệ điều hành khác nhau, chẳng hạn như Linux và Windows, chia
sẻ cùng một phần cứng vật lý.
Với các bộ chứa, nhiều ứng dụng chia sẻ cùng một phiên bản nhân hệ điều hành nhưng được tách biệt với nhau.
Nhân hệ điều hành là một phần của cái được gọi là hệ điều hành máy chủ. Hệ điều hành máy chủ nằm bên dưới các
thùng chứa và cung cấp các khả năng của hệ điều hành cho chúng. Các vùng chứa dành riêng cho dòng hệ điều hành;
máy chủ Linux chỉ có thể chạy các thùng chứa được xây dựng cho Linux và máy chủ Windows chỉ có thể chạy Windows
5
đ
n
b
Ất
p
cm NIST SP 800-190
điều hành đó.

hộp đựng. Ngoài ra, một vùng chứa được xây dựng cho một họ hệ điều hành sẽ chạy trên mọi hệ điều hành gần đây của họ hệ
Có hai loại hệ điều hành máy chủ chung được sử dụng để chạy các container. Hệ điều hành đa năng
như Red Hat Enterprise Linux, Ubuntu và Windows Server có thể được sử dụng để chạy nhiều loại ứng dụng và
có thể thêm chức năng dành riêng cho vùng chứa cho chúng. Các hệ điều hành dành riêng cho vùng chứa, như
CoreOS Container Linux [4], Project Atomic [5] và Hệ điều hành được tối ưu hóa cho vùng chứa của Google [6] là
các hệ điều hành tối giản được thiết kế rõ ràng để chỉ chạy các vùng chứa. Chúng thường không đi kèm với trình
quản lý gói, chúng chỉ có một tập hợp con các công cụ quản trị cốt lõi và chúng chủ động ngăn cản việc
chạy các ứng dụng bên ngoài vùng chứa. Thông thường, hệ điều hành dành riêng cho vùng chứa sử dụng thiết kế hệ
thống tệp chỉ đọc để giảm khả năng kẻ tấn công có thể lưu giữ dữ liệu trong đó và nó cũng sử dụng quy trình nâng
cấp đơn giản hóa vì có rất ít lo ngại về khả năng tương thích của ứng dụng.
Mọi hệ điều hành máy chủ được sử dụng để chạy vùng chứa đều có các tệp nhị phân thiết lập và duy trì
môi trường cho từng vùng chứa, còn được gọi là thời gian chạy vùng chứa. Thời gian chạy vùng chứa điều phối
nhiều thành phần hệ điều hành nhằm tách biệt tài nguyên và mức sử dụng tài nguyên để mỗi vùng chứa có chế
độ xem riêng của hệ điều hành và tách biệt với các vùng chứa khác đang chạy đồng thời. Thực tế, các vùng chứa
và hệ điều hành máy chủ tương tác thông qua thời gian chạy của vùng chứa.
Thời gian chạy vùng chứa cũng cung cấp các công cụ quản lý và giao diện lập trình ứng dụng (API) để cho phép
nhân viên DevOps và những người khác chỉ định cách chạy vùng chứa trên một máy chủ nhất định.
Thời gian chạy loại bỏ nhu cầu tạo thủ công tất cả các cấu hình cần thiết và đơn giản hóa quá trình
khởi động, dừng và vận hành vùng chứa. Ví dụ về thời gian chạy bao gồm Docker [2], rkt [3] và Daemon sáng
kiến vùng chứa mở [7].
Ví dụ về các khả năng kỹ thuật mà thời gian chạy vùng chứa đảm bảo hệ điều hành máy chủ cung cấp bao gồm:
• Cách ly không gian tên giới hạn những tài nguyên mà vùng chứa có thể tương tác. Điều này bao gồm hệ thống
tệp, giao diện mạng, liên lạc giữa các quá trình, tên máy chủ, thông tin người dùng và quy
trình. Việc cách ly không gian tên đảm bảo rằng các ứng dụng và quy trình bên trong vùng chứa chỉ nhìn
thấy các tài nguyên vật lý và ảo được phân bổ cho vùng chứa đó. Ví dụ: nếu bạn chạy 'ps –A' bên
trong vùng chứa chạy Apache trên máy chủ có nhiều vùng chứa khác chạy các ứng dụng khác, bạn sẽ chỉ thấy
httpd được liệt kê trong kết quả. Cách ly không gian tên cung cấp cho mỗi vùng chứa một ngăn xếp mạng
riêng, bao gồm các giao diện và địa chỉ IP duy nhất. Các bộ chứa trên Linux sử dụng các công
nghệ như nhận dạng quy trình được che giấu để đạt được sự cách ly không gian tên, trong khi trên
Windows, các không gian tên đối tượng được sử dụng.
• Việc phân bổ tài nguyên giới hạn số lượng tài nguyên của máy chủ mà một vùng chứa nhất định có thể
tiêu thụ. Ví dụ: nếu hệ điều hành máy chủ của bạn có tổng bộ nhớ là 10 gigabyte (GB), bạn có thể muốn
phân bổ 1 GB cho mỗi vùng chứa cho chín vùng chứa riêng biệt. Không có vùng chứa nào có thể can
thiệp vào hoạt động của vùng chứa khác, do đó việc phân bổ tài nguyên đảm bảo rằng mỗi vùng chứa chỉ có
thể sử dụng lượng tài nguyên được chỉ định cho nó. Trên Linux, đây là
6
đ
n
b
Ất
p
được thực hiện chủ yếu với các nhóm điều khiển (cgroups)4 , trong khi các đối tượng công việc trên Windows
phục vụ mục đích tương tự.
• Ảo hóa hệ thống tập tin cho phép nhiều vùng chứa chia sẻ cùng một bộ lưu trữ vật lý mà không có khả năng
truy cập hoặc thay đổi bộ lưu trữ của các vùng chứa khác. Mặc dù được cho là tương tự như cách ly
không gian tên, nhưng ảo hóa hệ thống tệp được gọi riêng vì nó cũng thường liên quan đến việc tối ưu hóa
để đảm bảo rằng các bộ chứa đang sử dụng hiệu quả bộ nhớ của máy chủ thông qua các kỹ thuật như sao chép
khi ghi. Ví dụ: nếu nhiều vùng chứa sử dụng cùng một hình ảnh đang chạy Apache trên một máy chủ, thì
việc ảo hóa hệ thống tệp sẽ đảm bảo rằng chỉ có một bản sao của tệp nhị phân httpd được lưu trữ trên
đĩa. Nếu một trong các vùng chứa sửa đổi các tệp bên trong chính nó, thì chỉ những bit được thay đổi
cụ thể mới được ghi vào đĩa và những thay đổi đó sẽ chỉ hiển thị đối với vùng chứa đã thực thi chúng.
Trên Linux, các khả năng này được cung cấp bởi các công nghệ như Hệ thống tệp hợp nhất nhiều lớp nâng
cao (AUFS), trong khi trên Windows, chúng là phần mở rộng của Hệ thống tệp NT
(NTFS).
Khả năng kỹ thuật của vùng chứa khác nhau tùy theo dòng hệ điều hành máy chủ. Về cơ bản, các vùng chứa là một cơ
chế nhằm cung cấp cho mỗi ứng dụng một cái nhìn riêng về một hệ điều hành duy nhất, vì vậy các công cụ
để đạt được sự tách biệt này phần lớn phụ thuộc vào dòng hệ điều hành. Ví dụ: các phương pháp được sử dụng để
tách biệt các tiến trình với nhau khác nhau giữa Linux và Windows. Tuy nhiên, mặc dù cách triển
khai cơ bản có thể khác nhau, nhưng thời gian chạy vùng chứa thường được sử dụng sẽ cung cấp một định
dạng giao diện chung giúp loại bỏ phần lớn những khác biệt này đối với người dùng.
Mặc dù các container cung cấp mức độ cách ly mạnh mẽ nhưng chúng không cung cấp ranh giới bảo mật rõ ràng và cụ
thể như VM. Bởi vì các container chia sẻ cùng một kernel và có thể chạy với các khả năng và đặc quyền khác
nhau trên máy chủ nên mức độ phân đoạn giữa chúng thấp hơn nhiều so với mức độ phân chia được cung cấp cho VM bởi
hypervisor. Do đó, các môi trường được cấu hình không cẩn thận có thể dẫn đến việc các thùng chứa có khả năng
tương tác với nhau và máy chủ dễ dàng và trực tiếp hơn nhiều máy ảo trên cùng một máy chủ.
Mặc dù các container đôi khi được coi là giai đoạn tiếp theo của ảo hóa, vượt qua ảo hóa phần cứng, nhưng
thực tế đối với hầu hết các tổ chức, nó không mang tính cách mạng mà là sự tiến hóa.
Các thùng chứa và ảo hóa phần cứng không chỉ có thể, mà còn rất thường xuyên, cùng tồn tại tốt và thực sự nâng
cao khả năng của nhau. Máy ảo mang lại nhiều lợi ích, chẳng hạn như khả năng cách ly mạnh mẽ, tự động hóa hệ điều
hành và hệ sinh thái giải pháp rộng và sâu. Các tổ chức không cần phải lựa chọn giữa container và VM. Thay vào
đó, các tổ chức có thể tiếp tục sử dụng máy ảo để triển khai, phân vùng và quản lý phần cứng của mình, đồng thời
sử dụng các bộ chứa để đóng gói ứng dụng và sử dụng từng máy ảo hiệu quả hơn.
2.3 Kiến trúc công nghệ vùng chứa
Hình 3 cho thấy năm tầng của kiến trúc công nghệ container:
4
cgroups là tập hợp các tiến trình có thể được quản lý độc lập, cung cấp cho kernel khả năng dựa trên phần mềm để đo lường
các hệ thống con như bộ nhớ, mức sử dụng bộ xử lý và I/O đĩa. Quản trị viên có thể kiểm soát các hệ thống con này theo
cách thủ công hoặc theo chương trình.
7
đ
n
b
Ất
p
cm NIST SP 800-190
hình ảnh và gửi hình ảnh đến cơ quan đăng ký)

1. Hệ thống dành cho nhà phát triển (tạo hình ảnh và gửi chúng để thử nghiệm và công nhận)
2. Hệ thống kiểm tra và công nhận (xác nhận và xác minh nội dung hình ảnh, ký tên
3. Cơ quan đăng ký (lưu trữ hình ảnh và phân phối hình ảnh cho người điều phối theo yêu cầu)
4. Orchestrator (chuyển đổi hình ảnh thành vùng chứa và triển khai vùng chứa lên máy chủ)
5. Host (chạy và dừng container theo chỉ dẫn của người điều phối)
Hình 3: Các tầng, thành phần và giai đoạn vòng đời của kiến trúc công nghệ container
Mặc dù có nhiều nhân vật hệ thống quản trị viên tham gia vào quá trình tổng thể, nhưng hình này chỉ
mô tả các hệ thống quản trị viên dành cho cơ quan đăng ký nội bộ và người điều phối.
Các hệ thống màu xám (hệ thống dành cho nhà phát triển, hệ thống kiểm tra và công nhận cũng như hệ
thống quản trị viên) nằm ngoài phạm vi của kiến trúc công nghệ vùng chứa nhưng chúng có những
tương tác quan trọng với kiến trúc đó. Trong hầu hết các tổ chức sử dụng vùng chứa, môi trường phát triển
và thử nghiệm cũng tận dụng vùng chứa và tính nhất quán này là một trong những lợi ích chính của việc sử
dụng vùng chứa. Tài liệu này không tập trung vào các hệ thống trong các môi trường này vì các
khuyến nghị để bảo mật chúng phần lớn giống với các khuyến nghị dành cho môi trường sản xuất.
Các hệ thống có màu xanh lục (đăng ký nội bộ, đăng ký bên ngoài và bộ điều phối) là các thành phần cốt lõi
của kiến trúc công nghệ vùng chứa. Cuối cùng, các hệ thống màu cam (máy chủ có vùng chứa) là nơi sử
dụng các vùng chứa.
Một cách khác để hiểu kiến trúc công nghệ container là xem xét container
các giai đoạn trong vòng đời, được mô tả ở cuối Hình 3. Ba giai đoạn được thảo luận chi tiết hơn dưới đây.
Bởi vì các tổ chức thường xây dựng và triển khai nhiều ứng dụng khác nhau cùng một lúc nên các giai đoạn
vòng đời này thường xảy ra đồng thời trong cùng một tổ chức và không được coi là các giai đoạn trưởng thành
lũy tiến. Thay vào đó, hãy coi chúng như những chu trình trong một động cơ hoạt động liên tục. Trong phép
ẩn dụ này, mỗi ứng dụng là một hình trụ bên trong động cơ và các ứng dụng khác nhau có thể ở các giai đoạn
khác nhau của vòng đời này cùng một lúc.
số 8
đ
n
b
Ất
p
cm NIST SP 800-190
2.3.1 Tạo, kiểm tra và công nhận hình ảnh

Trong giai đoạn đầu tiên của vòng đời vùng chứa, các thành phần của ứng dụng được xây dựng và đặt vào một hình
ảnh (hoặc có thể vào nhiều hình ảnh). Hình ảnh là một gói chứa tất cả các tệp cần thiết để chạy một vùng
chứa. Ví dụ: một hình ảnh để chạy Apache sẽ bao gồm tệp nhị phân httpd, cùng với các thư viện và tệp cấu hình liên
quan. Hình ảnh chỉ được bao gồm các tệp thực thi và thư viện do chính ứng dụng yêu cầu; tất cả các chức
năng hệ điều hành khác được cung cấp bởi nhân hệ điều hành trong hệ điều hành máy chủ cơ bản. Hình ảnh thường sử
dụng các kỹ thuật như phân lớp và sao chép khi ghi (trong đó hình ảnh chính được chia sẻ chỉ được đọc và các thay
đổi được ghi vào các tệp riêng biệt) để giảm thiểu kích thước của chúng trên đĩa và cải thiện hiệu quả hoạt động.
Vì hình ảnh được xây dựng theo lớp nên lớp bên dưới mà tất cả các thành phần khác được thêm vào thường được gọi
là lớp cơ sở. Các lớp cơ sở thường là các bản phân phối tối giản của các hệ điều hành phổ biến như Ubuntu và
Windows Nano Server với nhân hệ điều hành bị bỏ qua. Người dùng bắt đầu xây dựng hình ảnh đầy đủ của mình bằng
cách bắt đầu với một trong các lớp cơ sở này, sau đó thêm khung ứng dụng và mã tùy chỉnh của riêng họ để phát
triển hình ảnh có thể triển khai đầy đủ cho ứng dụng độc đáo của họ.
Thời gian chạy vùng chứa hỗ trợ sử dụng hình ảnh từ cùng một họ hệ điều hành, ngay cả khi phiên bản hệ điều hành
máy chủ cụ thể không giống nhau. Ví dụ: máy chủ Red Hat chạy Docker có thể chạy các hình ảnh được tạo trên
bất kỳ lớp cơ sở Linux nào, chẳng hạn như Alpine hoặc Ubuntu. Tuy nhiên, nó không thể chạy các hình ảnh được
tạo bằng lớp cơ sở Windows.
Quá trình tạo hình ảnh được quản lý bởi các nhà phát triển chịu trách nhiệm đóng gói ứng dụng để chuyển giao
cho thử nghiệm. Việc tạo hình ảnh thường sử dụng các công cụ tự động hóa và quản lý bản dựng, chẳng hạn như
Jenkins [8] và TeamCity [9], để hỗ trợ cái được gọi là quá trình “tích hợp liên tục”.
Các công cụ này lấy các thư viện, tệp nhị phân và các thành phần khác của ứng dụng, thực hiện thử nghiệm trên
chúng, sau đó tập hợp các hình ảnh từ chúng dựa trên bảng kê khai do nhà phát triển tạo mô tả cách xây dựng
hình ảnh cho ứng dụng.
Hầu hết các công nghệ vùng chứa đều có cách khai báo để mô tả các thành phần và yêu cầu đối với ứng
dụng. Ví dụ: một hình ảnh cho máy chủ web sẽ không chỉ bao gồm các tệp thực thi cho máy chủ web mà còn bao gồm
một số dữ liệu có thể phân tích cú pháp bằng máy để mô tả cách máy chủ web sẽ chạy, chẳng hạn như các cổng mà nó
nghe hoặc các thông số cấu hình mà nó sử dụng.
Sau khi tạo hình ảnh, các tổ chức thường tiến hành kiểm tra và công nhận. Ví dụ, kiểm tra
các công cụ tự động hóa và nhân viên sẽ sử dụng những hình ảnh được xây dựng để xác thực chức năng của ứng dụng
biểu mẫu cuối cùng và các nhóm bảo mật sẽ thực hiện công nhận trên chính những hình ảnh này.
Tính nhất quán của việc xây dựng, thử nghiệm và công nhận chính xác các tạo phẩm giống nhau cho một ứng dụng là
một trong những lợi ích bảo mật và vận hành chính của vùng chứa.
2.3.2 Lưu trữ và truy xuất hình ảnh
Hình ảnh thường được lưu trữ ở các vị trí trung tâm để dễ dàng kiểm soát, chia sẻ, tìm và sử dụng lại chúng trên
các máy chủ. Cơ quan đăng ký là các dịch vụ cho phép nhà phát triển dễ dàng lưu trữ hình ảnh khi chúng được tạo, gắn
thẻ và lập danh mục hình ảnh để nhận dạng và kiểm soát phiên bản nhằm hỗ trợ khám phá và tái sử dụng cũng như
tìm và tải xuống hình ảnh mà người khác đã tạo. Cơ quan đăng ký có thể được tự lưu trữ hoặc sử dụng như một dịch
vụ. Ví dụ về các cơ quan đăng ký bao gồm Cơ quan đăng ký vùng chứa Amazon EC2 [10],
Docker Hub [11], Cơ quan đăng ký đáng tin cậy của Docker [12] và Cơ quan đăng ký vùng chứa Quay [13].
9
đ
n
b
Ất
p
Cơ quan đăng ký cung cấp API cho phép tự động hóa các tác vụ phổ biến liên quan đến hình ảnh. Ví dụ:
các tổ chức có thể có trình kích hoạt trong giai đoạn tạo hình ảnh để tự động đẩy hình ảnh vào sổ đăng ký
sau khi vượt qua thử nghiệm. Sổ đăng ký có thể có thêm trình kích hoạt tự động hóa việc triển khai hình ảnh
mới sau khi chúng được thêm vào. Tính năng tự động hóa này cho phép lặp lại các dự án nhanh hơn với kết quả
nhất quán hơn.
Sau khi được lưu trữ trong sổ đăng ký, hình ảnh có thể dễ dàng được kéo và sau đó được các cá nhân DevOps
chạy trên bất kỳ môi trường nào mà chúng chạy vùng chứa. Đây là một ví dụ khác về lợi ích của khả năng di
chuyển của container; Việc tạo hình ảnh có thể xảy ra trong nhà cung cấp đám mây công cộng, việc này sẽ đẩy
hình ảnh đến sổ đăng ký được lưu trữ trên đám mây riêng, sau đó được sử dụng để phân phối hình ảnh để chạy ứng
dụng ở vị trí thứ ba.
2.3.3 Triển khai và quản lý vùng chứa
Các công cụ được gọi là bộ điều phối cho phép các cá nhân DevOps hoặc tính năng tự động hóa hoạt động thay
mặt họ để lấy hình ảnh từ cơ quan đăng ký, triển khai những hình ảnh đó vào vùng chứa và quản lý các
vùng chứa đang chạy. Quá trình triển khai này thực sự mang lại một phiên bản ứng dụng có thể sử dụng
được, chạy và sẵn sàng đáp ứng các yêu cầu. Khi một hình ảnh được triển khai vào vùng chứa, bản thân hình ảnh
đó không bị thay đổi mà thay vào đó, một bản sao của hình ảnh đó được đặt trong vùng chứa và chuyển từ trạng
thái là một bộ mã ứng dụng không hoạt động sang một phiên bản đang chạy của ứng dụng. Ví dụ về các bộ điều
phối là Kubernetes [14], Mesos [15] và Docker Swarm [16].
Lưu ý rằng việc triển khai vùng chứa nhỏ, đơn giản có thể bỏ qua một bộ điều phối chính thức.
Người điều phối cũng có thể bị phá vỡ hoặc không cần thiết trong các trường hợp khác. Ví dụ: Máy chủ có thể
liên hệ trực tiếp với cơ quan đăng ký để lấy hình ảnh từ cơ quan đăng ký đó cho thời gian chạy vùng chứa. Để
đơn giản hóa các cuộc thảo luận trong ấn phẩm này, việc sử dụng một bộ điều phối sẽ được giả định.
Khả năng trừu tượng hóa do người điều phối cung cấp cho phép nhân viên DevOps chỉ định một cách đơn giản
số lượng vùng chứa cần chạy một hình ảnh nhất định và những tài nguyên nào, chẳng hạn như bộ nhớ,
quá trình xử lý và ổ đĩa cần được phân bổ cho từng vùng chứa. Người điều phối biết trạng thái của từng máy
chủ trong cụm, bao gồm những tài nguyên nào có sẵn cho mỗi máy chủ và xác định vùng chứa nào sẽ chạy trên
máy chủ nào. Sau đó, người điều phối sẽ lấy các hình ảnh được yêu cầu từ sổ đăng ký và chạy chúng dưới
dạng vùng chứa với các tài nguyên được chỉ định.
Các công cụ điều phối cũng chịu trách nhiệm giám sát mức tiêu thụ tài nguyên vùng chứa, thực hiện công
việc và tình trạng máy trên các máy chủ. Tùy thuộc vào cấu hình của nó, bộ điều phối có thể tự động khởi động
lại các thùng chứa trên máy chủ mới nếu máy chủ mà chúng chạy ban đầu bị lỗi.
Nhiều bộ điều phối cho phép khám phá dịch vụ và mạng container trên nhiều máy chủ. Hầu hết các bộ
điều phối cũng bao gồm thành phần mạng được xác định bằng phần mềm (SDN) được gọi là mạng lớp phủ có thể được
sử dụng để cách ly giao tiếp giữa các ứng dụng dùng chung mạng vật lý.
Khi các ứng dụng trong vùng chứa cần được cập nhật, các vùng chứa hiện tại sẽ không bị thay đổi mà thay vào
đó chúng sẽ bị hủy và các vùng chứa mới được tạo từ hình ảnh được cập nhật. Đây là điểm khác biệt chính
về hoạt động với các bộ chứa: phần mềm cơ bản từ quá trình triển khai ban đầu sẽ không thay đổi theo thời
gian và các bản cập nhật được thực hiện bằng cách thay thế toàn bộ hình ảnh cùng một lúc. Cách tiếp
cận này có những lợi ích bảo mật tiềm năng đáng kể vì nó cho phép các tổ chức xây dựng, kiểm tra, xác thực và
10
đ
n
b
Ất
p
triển khai chính xác cùng một phần mềm với cùng một cấu hình trong từng giai đoạn. Khi các bản cập nhật được
thực hiện cho ứng dụng, các tổ chức có thể đảm bảo rằng các phiên bản mới nhất được sử dụng, thường
bằng cách tận dụng các bộ điều phối. Người điều phối thường được định cấu hình để lấy phiên bản cập nhật nhất
của hình ảnh từ sổ đăng ký để ứng dụng luôn được cập nhật. Tính năng tự động hóa “phân phối liên tục” này
cho phép các nhà phát triển chỉ cần xây dựng phiên bản hình ảnh mới cho ứng dụng của họ, kiểm tra hình ảnh,
đẩy nó vào sổ đăng ký và sau đó dựa vào các công cụ tự động hóa để triển khai nó vào môi trường đích.
Điều này có nghĩa là tất cả việc quản lý lỗ hổng bảo mật, bao gồm các bản vá và cài đặt cấu hình, thường
được nhà phát triển quan tâm khi xây dựng phiên bản hình ảnh mới. Với vùng chứa, nhà phát triển chịu trách
nhiệm phần lớn về tính bảo mật của ứng dụng và hình ảnh thay vì nhóm vận hành. Sự thay đổi trách nhiệm này
thường đòi hỏi sự phối hợp và hợp tác giữa các nhân viên nhiều hơn mức cần thiết trước đây. Các tổ chức áp
dụng bộ chứa phải đảm bảo rằng các luồng quy trình rõ ràng và trách nhiệm của nhóm được thiết lập cho
từng nhóm bên liên quan.
Quản lý container bao gồm quản lý và giám sát an ninh. Tuy nhiên, các biện pháp kiểm soát bảo mật được
thiết kế cho môi trường không có vùng chứa thường không phù hợp để sử dụng với vùng chứa. Ví dụ:
hãy xem xét các biện pháp kiểm soát bảo mật có tính đến địa chỉ IP. Điều này hoạt động tốt đối với máy
ảo và máy chủ kim loại trần có địa chỉ IP tĩnh được giữ nguyên trong nhiều tháng hoặc nhiều năm. Ngược
lại, các bộ chứa thường được các nhà điều phối phân bổ địa chỉ IP và do các bộ chứa được tạo và hủy thường
xuyên hơn nhiều so với VM nên các địa chỉ IP này cũng thay đổi thường xuyên theo thời gian. Điều
này gây khó khăn hoặc không thể bảo vệ vùng chứa bằng các kỹ thuật bảo mật dựa trên địa chỉ IP tĩnh, chẳng
hạn như bộ quy tắc tường lửa lọc lưu lượng truy cập dựa trên địa chỉ IP. Ngoài ra, mạng container có thể
bao gồm thông tin liên lạc giữa các container trên cùng một nút, trên các nút khác nhau và
thậm chí trên các đám mây.
2.4 Sử dụng thùng chứa
Giống như bất kỳ công nghệ nào khác, container không phải là thuốc chữa bách bệnh. Chúng là công cụ có
giá trị cho nhiều tình huống nhưng không nhất thiết phải là lựa chọn tốt nhất cho mọi tình
huống. Ví dụ: một tổ chức có nền tảng phần mềm cũ sẵn có lớn khó có thể tận dụng được bộ chứa để chạy
hầu hết phần mềm đó vì các nhà cung cấp có thể không hỗ trợ phần mềm đó.
Tuy nhiên, hầu hết các tổ chức sẽ có nhiều mục đích sử dụng có giá trị đối với vùng chứa. Những ví dụ bao gồm:
• Phát triển linh hoạt, nơi các ứng dụng được cập nhật và triển khai thường xuyên. Tính di động và tính
chất khai báo của vùng chứa làm cho các bản cập nhật thường xuyên này hiệu quả hơn và dễ kiểm tra
hơn. Điều này cho phép các tổ chức tăng tốc đổi mới và cung cấp phần mềm nhanh hơn. Điều này cũng
cho phép sửa các lỗ hổng trong mã ứng dụng và phần mềm cập nhật được kiểm tra và triển khai nhanh hơn
nhiều.
• Tính nhất quán và phân chia môi trường, nơi các nhà phát triển có thể có
môi trường giống hệt nhau nhưng riêng biệt để xây dựng, thử nghiệm và chạy ứng dụng. Vùng chứa cung
cấp cho nhà phát triển khả năng chạy toàn bộ bản sao chính xác của ứng dụng sản xuất cục bộ
trên hệ thống máy tính xách tay phát triển, hạn chế nhu cầu phối hợp và chia sẻ môi trường thử nghiệm
cũng như loại bỏ những rắc rối của môi trường thử nghiệm cũ.
11
đ
n
b
Ất
p
• Tình huống 'Mở rộng quy mô', trong đó một ứng dụng có thể cần triển khai hoặc ngừng hoạt động nhiều phiên
bản mới một cách nhanh chóng tùy thuộc vào tải tại một thời điểm nhất định. Tính bất biến
của vùng chứa giúp việc mở rộng quy mô các phiên bản một cách đáng tin cậy dễ dàng hơn, biết rằng mỗi
phiên bản đều giống hệt với tất cả các phiên bản khác. Hơn nữa, vì các container thường không có
trạng thái nên việc ngừng hoạt động của chúng sẽ dễ dàng hơn khi không còn cần thiết nữa.
• Ứng dụng dựa trên nền tảng đám mây, nơi các nhà phát triển có thể xây dựng kiến trúc vi dịch vụ ngay từ đầu,
đảm bảo việc lặp lại ứng dụng hiệu quả hơn và triển khai đơn giản hóa.
Container cung cấp các lợi ích bổ sung; ví dụ: chúng có thể tăng hiệu quả của quy trình xây dựng do tính chất bất
biến của hình ảnh vùng chứa. Container chuyển đổi thời gian, địa điểm lắp đặt mã sản xuất. Trong các hệ thống không
chứa, quá trình cài đặt ứng dụng diễn ra trong quá trình sản xuất (tức là trong thời gian chạy của máy chủ), thường
bằng cách chạy các tập lệnh thủ công quản lý việc cài đặt mã ứng dụng (ví dụ: thời gian chạy ngôn ngữ lập trình, thư
viện bên thứ ba phụ thuộc, tập lệnh init và hệ điều hành công cụ) trên máy chủ. Điều này có nghĩa là bất kỳ thử
nghiệm nào chạy trong quy trình xây dựng tiền sản xuất (và trên máy trạm của nhà phát triển) đều không kiểm tra
tạo phẩm sản xuất thực tế mà là giá trị gần đúng dự đoán tốt nhất có trong hệ thống xây dựng. Sản lượng
gần đúng này có xu hướng lệch khỏi sản xuất theo thời gian, đặc biệt nếu các nhóm quản lý sản xuất và hệ thống
xây dựng khác nhau. Kịch bản này là hiện thân của vấn đề “nó hoạt động trên máy của tôi”.
Với công nghệ vùng chứa, hệ thống xây dựng sẽ cài đặt ứng dụng trong hình ảnh mà nó tạo ra (tức là tại thời điểm
biên dịch). Hình ảnh này là ảnh chụp nhanh bất biến về tất cả các yêu cầu về không gian người dùng của ứng dụng
(ví dụ: thời gian chạy ngôn ngữ lập trình, thư viện phụ thuộc của bên thứ ba, tập lệnh init và công cụ hệ điều hành).
Trong quá trình sản xuất, hình ảnh vùng chứa do hệ thống xây dựng xây dựng chỉ cần tải xuống và chạy. Điều này
giải quyết vấn đề “hoạt động trên máy của tôi” vì nhà phát triển, hệ thống xây dựng và quá trình sản xuất đều
chạy cùng một tạo phẩm bất biến.
Các công nghệ vùng chứa hiện đại cũng thường nhấn mạnh đến việc tái sử dụng, sao cho hình ảnh vùng chứa do một nhà
phát triển tạo ra có thể dễ dàng được chia sẻ và sử dụng lại bởi các nhà phát triển khác, trong cùng một khu vực.
tổ chức hoặc giữa các tổ chức khác. Dịch vụ đăng ký cung cấp dịch vụ khám phá và chia sẻ hình ảnh tập trung để giúp
nhà phát triển dễ dàng tìm và sử dụng lại phần mềm do người khác tạo. Tính dễ sử dụng này cũng khiến nhiều
nhà cung cấp và dự án phần mềm phổ biến sử dụng container như một cách giúp khách hàng dễ dàng tìm thấy và
nhanh chóng chạy phần mềm của họ. Ví dụ: thay vì cài đặt trực tiếp một ứng dụng như MongoDB trên hệ điều hành
máy chủ, người dùng có thể chỉ cần chạy hình ảnh vùng chứa của MongoDB. Hơn nữa, do thời gian chạy vùng chứa cách
ly các vùng chứa với nhau và hệ điều hành máy chủ, nên các ứng dụng này có thể chạy an toàn và đáng tin cậy hơn, đồng
thời người dùng không phải lo lắng về việc chúng làm phiền hệ điều hành máy chủ cơ bản.
12
đ
n
b
Ất
p
cm NIST SP 800-190
3 rủi ro chính đối với các thành phần cốt lõi của công nghệ container
Phần này xác định và phân tích các rủi ro chính đối với các thành phần cốt lõi của công nghệ vùng
chứa—hình ảnh, sổ đăng ký, bộ điều phối, vùng chứa và hệ điều hành máy chủ. Vì phân tích chỉ xem xét các thành
phần cốt lõi nên nó có thể áp dụng cho hầu hết các hoạt động triển khai vùng chứa bất kể công nghệ vùng
chứa, nền tảng hệ điều hành máy chủ hoặc vị trí (đám mây công cộng, đám mây riêng, v.v.). Hai loại rủi ro được
xem xét:
1. Xâm phạm hình ảnh hoặc vùng chứa. Rủi ro này được đánh giá bằng cách sử dụng dữ liệu tập trung
phương pháp mô hình hóa mối đe dọa hệ thống được mô tả trong NIST SP 800-154 [17]. “Dữ liệu” chính cần
bảo vệ là hình ảnh và vùng chứa, có thể chứa tệp ứng dụng, tệp dữ liệu, v.v. Dữ liệu thứ cấp cần
bảo vệ là dữ liệu vùng chứa trong các tài nguyên máy chủ được chia sẻ như bộ nhớ, bộ lưu trữ và giao
diện mạng.
2. Lạm dụng container để tấn công container khác, hệ điều hành máy chủ, máy chủ khác, v.v.
Tất cả các rủi ro khác liên quan đến các thành phần cốt lõi cũng như các rủi ro liên quan đến các thành phần
công nghệ container không cốt lõi, bao gồm hệ thống dành cho nhà phát triển, hệ thống kiểm tra và công
nhận, hệ thống quản trị viên cũng như phần cứng máy chủ và trình quản lý máy ảo, đều nằm ngoài phạm vi của tài
liệu này. Phụ lục A chứa các gợi ý tới các tài liệu tham khảo chung để bảo mật các thành phần công nghệ
vùng chứa không cốt lõi.
3.1 Rủi ro về hình ảnh
3.1.1 Lỗ hổng hình ảnh
Vì hình ảnh là các tệp lưu trữ tĩnh thực sự bao gồm tất cả các thành phần dùng để chạy một ứng dụng nhất định
nên các thành phần trong hình ảnh có thể thiếu các bản cập nhật bảo mật quan trọng hoặc đã lỗi thời. Một hình ảnh
được tạo bằng các thành phần cập nhật đầy đủ có thể không có lỗ hổng đã biết trong nhiều ngày hoặc
nhiều tuần sau khi được tạo, nhưng đôi khi các lỗ hổng sẽ được phát hiện trong một hoặc nhiều thành phần
hình ảnh và do đó hình ảnh sẽ không còn cập nhật nữa- cho đến nay.
Không giống như các mô hình hoạt động truyền thống trong đó phần mềm đã triển khai được cập nhật 'tại hiện trường'
trên các máy chủ mà nó chạy trên đó, với các bộ chứa, các bản cập nhật này phải được thực hiện ngược dòng trong
chính hình ảnh, sau đó được triển khai lại. Do đó, một rủi ro phổ biến trong môi trường được chứa trong
container là các container được triển khai có lỗ hổng bảo mật do phiên bản của hình ảnh được sử dụng để tạo các container
có lỗ hổng.
3.1.2 Lỗi cấu hình hình ảnh
Ngoài lỗi phần mềm, hình ảnh cũng có thể bị lỗi về cấu hình. Ví dụ: một hình ảnh có thể không được định cấu
hình bằng một tài khoản người dùng cụ thể để “chạy dưới dạng” và do đó chạy với các đặc quyền lớn hơn mức cần
thiết. Một ví dụ khác, một hình ảnh có thể bao gồm daemon SSH, điều này khiến vùng chứa gặp rủi ro mạng
không cần thiết. Giống như trong máy chủ hoặc VM truyền thống, trong đó cấu hình kém vẫn có thể khiến hệ
thống cập nhật đầy đủ bị tấn công, do đó, hình ảnh được cấu hình kém cũng có thể làm tăng rủi ro ngay cả
khi tất cả các thành phần đi kèm đều được cập nhật.
13
đ
n
b
Ất
p
cm NIST SP 800-190
3.1.3 Phần mềm độc hại nhúng

Vì hình ảnh chỉ là tập hợp các tệp được đóng gói cùng nhau nên các tệp độc hại có thể được đưa vào một cách cố ý hoặc vô
tình trong đó. Phần mềm độc hại như vậy sẽ có khả năng tương tự như bất kỳ thành phần nào khác trong hình ảnh và do
đó có thể được sử dụng để tấn công các vùng chứa hoặc máy chủ khác trong môi trường. Một nguồn có thể có của phần mềm
độc hại được nhúng là việc sử dụng các lớp cơ sở và các hình ảnh khác do bên thứ ba cung cấp mà không rõ nguồn gốc
đầy đủ.
3.1.4 Bí mật văn bản rõ ràng được nhúng
Nhiều ứng dụng yêu cầu bí mật để cho phép liên lạc an toàn giữa các thành phần. Ví dụ: một ứng dụng web có thể cần tên
người dùng và mật khẩu để kết nối với cơ sở dữ liệu phụ trợ. Các ví dụ khác về bí mật được nhúng bao gồm chuỗi kết nối,
khóa riêng SSH và khóa riêng X.509.
Khi một ứng dụng được đóng gói thành một hình ảnh, những bí mật này có thể được nhúng trực tiếp vào hình ảnh
hệ thống tập tin. Tuy nhiên, cách làm này tạo ra rủi ro bảo mật vì bất kỳ ai có quyền truy cập vào hình ảnh đều có
thể dễ dàng phân tích cú pháp để tìm hiểu những bí mật này.
3.1.5 Sử dụng hình ảnh không đáng tin cậy
Một trong những tình huống rủi ro cao phổ biến nhất trong mọi môi trường là việc thực thi phần mềm không đáng tin cậy.
Tính di động và dễ dàng tái sử dụng các vùng chứa làm tăng khả năng các nhóm chạy hình ảnh từ các nguồn bên ngoài có thể
không được xác thực tốt hoặc đáng tin cậy. Ví dụ: khi khắc phục sự cố với ứng dụng web, người dùng có thể tìm thấy phiên
bản khác của ứng dụng đó trong hình ảnh do bên thứ ba cung cấp. Việc sử dụng hình ảnh do bên ngoài cung cấp này sẽ dẫn
đến các loại rủi ro giống như phần mềm bên ngoài thường gặp phải, chẳng hạn như giới thiệu phần mềm độc hại, rò rỉ dữ
liệu hoặc bao gồm các thành phần có lỗ hổng bảo mật.
3.2 Rủi ro đăng ký
3.2.1 Kết nối tới cơ quan đăng ký không an toàn
Hình ảnh thường chứa các thành phần nhạy cảm như phần mềm độc quyền của tổ chức và các bí mật được nhúng. Nếu kết
nối tới cơ quan đăng ký được thực hiện qua các kênh không an toàn thì nội dung của hình ảnh sẽ phải chịu rủi ro bảo mật
giống như bất kỳ dữ liệu nào khác được truyền rõ ràng.
Ngoài ra còn có nguy cơ gia tăng các cuộc tấn công trung gian có thể chặn lưu lượng truy cập mạng dành cho cơ quan đăng
ký và đánh cắp thông tin xác thực của nhà phát triển hoặc quản trị viên trong lưu lượng truy cập đó, cung cấp hình ảnh
gian lận hoặc lỗi thời cho người điều phối, v.v.
3.2.2 Hình ảnh cũ trong sổ đăng ký
Vì các cơ quan đăng ký thường là vị trí nguồn cho tất cả các hình ảnh mà một tổ chức triển khai nên theo thời gian,
tập hợp hình ảnh mà chúng lưu trữ có thể bao gồm nhiều phiên bản lỗi thời, dễ bị tấn công. Mặc dù những hình ảnh dễ bị
tổn thương này không trực tiếp gây ra mối đe dọa chỉ bằng cách được lưu trữ trong sổ đăng ký, nhưng chúng làm tăng khả
năng vô tình triển khai một phiên bản dễ bị tổn thương đã biết.
3.2.3 Hạn chế xác thực và ủy quyền không đầy đủ
Vì các cơ quan đăng ký có thể chứa hình ảnh được sử dụng để chạy các ứng dụng nhạy cảm hoặc độc quyền và để truy cập
dữ liệu nhạy cảm nên các yêu cầu xác thực và ủy quyền không đầy đủ có thể dẫn đến các vi phạm trí tuệ.
14
đ
n
bt
p
mất tài sản và tiết lộ các chi tiết kỹ thuật quan trọng về ứng dụng cho kẻ tấn công. Thậm chí quan trọng
hơn, vì các cơ quan đăng ký thường được tin cậy như một nguồn phần mềm hợp lệ, được phê duyệt, việc
xâm phạm sổ đăng ký có thể có khả năng dẫn đến sự xâm phạm các vùng chứa phía dưới và
chủ nhà.
3.3 Rủi ro của người điều phối

Ấ
3.3.1 Truy cập quản trị không giới hạn
Trong lịch sử, nhiều bộ điều phối được thiết kế với giả định rằng tất cả người dùng tương tác
cùng với họ sẽ là quản trị viên và những quản trị viên đó sẽ có quyền kiểm soát trên toàn môi trường.
Tuy nhiên, trong nhiều trường hợp, một người điều phối có thể chạy nhiều ứng dụng khác nhau, mỗi ứng
dụng do các nhóm khác nhau quản lý và có mức độ nhạy cảm khác nhau. Nếu quyền truy cập được cung cấp cho
người dùng và nhóm không nằm trong phạm vi nhu cầu cụ thể của họ thì người dùng cố ý hoặc bất cẩn có
thể ảnh hưởng hoặc phá hoại hoạt động của các vùng chứa khác do người điều phối quản lý.
3.3.2 Truy cập trái phép
Người điều phối thường bao gồm dịch vụ thư mục xác thực của riêng họ, dịch vụ này có thể tách biệt với
các thư mục thông thường đã được sử dụng trong một tổ chức. Điều này có thể dẫn đến thực tiễn quản lý
tài khoản yếu hơn và các tài khoản 'mồ côi' trong bộ điều phối vì các hệ thống này được quản lý kém
chặt chẽ hơn. Bởi vì nhiều tài khoản trong số này có đặc quyền cao trong bộ điều phối nên việc xâm phạm
chúng có thể dẫn đến xâm phạm toàn hệ thống.
Các vùng chứa thường sử dụng khối lượng lưu trữ dữ liệu được quản lý bởi công cụ điều phối và không dành
riêng cho máy chủ. Vì vùng chứa có thể chạy trên bất kỳ nút cụ thể nào trong một cụm nên dữ liệu mà
ứng dụng yêu cầu trong vùng chứa phải có sẵn cho vùng chứa bất kể nút nào
máy chủ nó đang chạy. Đồng thời, nhiều tổ chức quản lý dữ liệu phải được mã hóa ở phần còn lại để ngăn chặn
truy cập trái phép.
3.3.3 Lưu lượng mạng liên vùng bị phân tách kém
Trong hầu hết các môi trường được chứa trong container, lưu lượng giữa các nút riêng lẻ được định tuyến
qua mạng lớp phủ ảo. Mạng lớp phủ này thường được quản lý bởi người điều phối và thường không rõ ràng
đối với các công cụ quản lý và bảo mật mạng hiện có. Ví dụ: thay vì nhìn thấy các truy vấn cơ sở dữ
liệu được gửi từ vùng chứa máy chủ web đến vùng chứa cơ sở dữ liệu trên một máy chủ khác, các bộ lọc mạng
truyền thống sẽ chỉ thấy các gói được mã hóa truyền giữa hai máy chủ mà không hiển thị được điểm cuối của
vùng chứa thực tế cũng như lưu lượng truy cập được gửi . Mặc dù mạng lớp phủ được mã hóa mang lại nhiều
lợi ích về vận hành và bảo mật nhưng nó cũng có thể tạo ra tình huống 'mù' về bảo mật trong đó các tổ
chức không thể giám sát hiệu quả lưu lượng truy cập trong mạng của chính họ.
Nguy cơ thậm chí còn nghiêm trọng hơn là nguy cơ lưu lượng truy cập từ các ứng dụng khác nhau chia sẻ cùng
một mạng ảo. Nếu các ứng dụng có mức độ nhạy cảm khác nhau, chẳng hạn như trang web công khai và ứng dụng
quản lý ngân quỹ nội bộ, đang sử dụng cùng một mạng ảo thì các ứng dụng nội bộ nhạy cảm có thể gặp rủi
ro cao hơn do bị tấn công mạng. Ví dụ: nếu trang web công khai bị xâm phạm, kẻ tấn công có thể sử
dụng mạng chia sẻ để tấn công ứng dụng kho bạc.
15
đ
n
b
Ất
p
cm NIST SP 800-190
3.3.4 Trộn các mức độ nhạy cảm của khối lượng công việc
Người điều phối thường tập trung chủ yếu vào việc thúc đẩy quy mô và mật độ khối lượng công việc. Điều này có nghĩa
là, theo mặc định, họ có thể đặt khối lượng công việc có mức độ nhạy cảm khác nhau trên cùng một máy chủ.
Ví dụ: trong cấu hình mặc định, người điều phối có thể đặt một vùng chứa chạy máy chủ web công khai trên cùng
một máy chủ đang xử lý dữ liệu tài chính nhạy cảm, đơn giản vì máy chủ đó có nhiều tài nguyên sẵn có nhất tại
thời điểm triển khai. Trong trường hợp có lỗ hổng nghiêm trọng trong máy chủ web, điều này có thể khiến bộ chứa xử
lý dữ liệu tài chính nhạy cảm có nguy cơ bị xâm phạm cao hơn đáng kể.
3.3.5 Sự tin cậy của nút soạn thảo
Việc duy trì sự tin cậy giữa các nút trong môi trường cần được chăm sóc đặc biệt. Bộ điều phối là nút
cơ bản nhất. Cấu hình bộ điều phối yếu có thể khiến bộ điều phối và tất cả các thành phần công nghệ vùng chứa
khác gặp rủi ro gia tăng. Ví dụ về các hậu quả có thể xảy ra bao gồm:
• Máy chủ trái phép tham gia cụm và chạy vùng chứa
• Sự xâm phạm của một máy chủ cụm duy nhất có nghĩa là sự xâm phạm của toàn bộ cụm—ví dụ: nếu các cặp khóa
giống nhau được sử dụng để xác thực được chia sẻ trên tất cả các nút
• Thông tin liên lạc giữa người điều phối và nhân viên DevOps, quản trị viên và
máy chủ không được mã hóa và không được xác thực
3.4 Rủi ro về container
3.4.1 Lỗ hổng trong phần mềm thời gian chạy
Mặc dù tương đối hiếm gặp nhưng các lỗ hổng trong phần mềm thời gian chạy đặc biệt nguy hiểm nếu chúng
cho phép các tình huống 'thoát vùng chứa' trong đó phần mềm độc hại có thể tấn công tài nguyên trong các vùng
chứa khác và chính hệ điều hành máy chủ. Kẻ tấn công cũng có thể khai thác các lỗ hổng để xâm phạm chính
phần mềm thời gian chạy, sau đó thay đổi phần mềm đó để cho phép kẻ tấn công truy cập vào các vùng chứa khác, giám
sát thông tin liên lạc giữa các vùng chứa, v.v.
3.4.2 Truy cập mạng không giới hạn từ container
Theo mặc định trong hầu hết thời gian chạy của vùng chứa, các vùng chứa riêng lẻ có thể truy cập lẫn nhau và hệ
điều hành máy chủ qua mạng. Nếu một vùng chứa bị xâm phạm và hoạt động độc hại, việc cho phép lưu lượng truy
cập mạng này có thể khiến các tài nguyên khác trong môi trường gặp rủi ro. Ví dụ: một vùng chứa bị xâm
nhập có thể được sử dụng để quét mạng mà nó được kết nối nhằm tìm ra các điểm yếu khác để kẻ tấn công khai thác.
Rủi ro này liên quan đến rủi ro từ các mạng ảo được phân tách kém, như đã thảo luận trong Phần 3.3.3, nhưng
khác vì nó tập trung nhiều hơn vào các luồng từ vùng chứa đến bất kỳ đích đi nào, chứ không phải vào các tình
huống “thảo luận chéo” của ứng dụng.
Việc quản lý truy cập mạng đầu ra phức tạp hơn trong môi trường được chứa trong vùng chứa vì rất nhiều kết nối
được ảo hóa giữa các vùng chứa. Do đó, lưu lượng từ vùng chứa này sang vùng chứa khác có thể xuất hiện đơn
giản dưới dạng các gói được đóng gói trên mạng mà không trực tiếp chỉ ra
nguồn, đích cuối cùng hoặc tải trọng cuối cùng. Các công cụ và quy trình vận hành không nhận biết được
vùng chứa sẽ không thể kiểm tra lưu lượng truy cập này hoặc xác định xem liệu nó có phải là mối đe dọa hay không.
16
đ
n
b
Ất
p
cm NIST SP 800-190
3.4.3 Cấu hình thời gian chạy vùng chứa không an toàn
Thời gian chạy vùng chứa thường hiển thị nhiều tùy chọn có thể định cấu hình cho quản trị viên. Việc đặt chúng
không đúng cách có thể làm giảm tính bảo mật tương đối của hệ thống. Ví dụ: trên máy chủ bộ chứa Linux, tập hợp các
cuộc gọi hệ thống được phép thường bị giới hạn theo mặc định ở những yêu cầu cần thiết để vận hành an toàn
các bộ chứa. Nếu danh sách này được mở rộng, nó có thể khiến các vùng chứa và hệ điều hành máy chủ gặp rủi
ro gia tăng từ vùng chứa bị xâm nhập. Tương tự, nếu một vùng chứa được chạy ở chế độ đặc quyền, thì nó có quyền truy
cập vào tất cả các thiết bị trên máy chủ, do đó về cơ bản cho phép nó hoạt động như một phần của Hệ điều hành máy
chủ và tác động đến tất cả các vùng chứa khác đang chạy trên đó.
Một ví dụ khác về cấu hình thời gian chạy không an toàn là cho phép các thùng chứa gắn các thư mục nhạy cảm trên
máy chủ. Các bộ chứa hiếm khi thực hiện thay đổi đối với hệ thống tệp Hệ điều hành máy chủ và hầu như không bao
giờ thực hiện thay đổi đối với các vị trí kiểm soát chức năng cơ bản của Hệ điều hành máy chủ
(ví dụ: /boot hoặc /etc cho bộ chứa Linux, C:\Windows cho bộ chứa Windows). Nếu một vùng chứa bị xâm nhập được phép
thực hiện các thay đổi đối với các đường dẫn này, nó có thể được sử dụng để nâng cao đặc quyền và tấn công chính
máy chủ cũng như các vùng chứa khác đang chạy trên máy chủ đó.
3.4.4 Lỗ hổng ứng dụng
Ngay cả khi các tổ chức đang thực hiện các biện pháp phòng ngừa được đề xuất trong hướng dẫn này, các vùng chứa vẫn
có thể bị xâm phạm do sai sót trong ứng dụng mà chúng chạy. Bản thân đây không phải là vấn đề với vùng chứa mà
thay vào đó chỉ là biểu hiện của các lỗi phần mềm điển hình trong môi trường vùng chứa. Ví dụ: một ứng dụng
web được chứa trong bộ chứa có thể dễ bị tấn công bởi các lỗ hổng tập lệnh chéo trang và bộ chứa giao diện người
dùng cơ sở dữ liệu có thể bị chèn vào Ngôn ngữ truy vấn có cấu trúc (SQL). Khi một vùng chứa bị xâm phạm, nó có thể
bị lạm dụng theo nhiều cách, chẳng hạn như cấp quyền truy cập trái phép vào thông tin nhạy cảm hoặc tạo điều
kiện cho các cuộc tấn công chống lại các vùng chứa khác hoặc hệ điều hành máy chủ.
3.4.5 Thùng chứa giả mạo
Vùng chứa giả mạo là vùng chứa không được lên kế hoạch hoặc không được phê duyệt trong một môi trường. Đây có
thể là một trường hợp phổ biến, đặc biệt là trong môi trường phát triển, nơi các nhà phát triển ứng dụng có thể khởi
chạy vùng chứa như một phương tiện để kiểm tra mã của họ. Nếu những vùng chứa này không được thực hiện nghiêm ngặt
trong quá trình quét lỗ hổng và cấu hình phù hợp, chúng có thể dễ bị khai thác hơn.
Do đó, các container giả mạo gây thêm rủi ro cho tổ chức, đặc biệt là khi chúng tồn tại trong môi trường mà các nhóm
phát triển và quản trị viên bảo mật không hề hay biết.
3.5 Rủi ro hệ điều hành máy chủ
3.5.1 Bề mặt tấn công lớn
Mọi hệ điều hành máy chủ đều có một bề mặt tấn công, là tập hợp tất cả các cách mà kẻ tấn công có thể cố gắng truy
cập và khai thác các lỗ hổng của hệ điều hành máy chủ. Ví dụ: bất kỳ dịch vụ có thể truy cập mạng nào đều cung
cấp điểm xâm nhập tiềm năng cho những kẻ tấn công, bổ sung thêm vào bề mặt tấn công. Bề mặt tấn công càng lớn thì
khả năng kẻ tấn công có thể tìm và truy cập vào lỗ hổng càng cao, dẫn đến sự xâm phạm hệ điều hành máy chủ và các
container chạy trên nó.
17
đ
n
b
Ất
p
cm NIST SP 800-190
3.5.2 Hạt nhân dùng chung

Các hệ điều hành dành riêng cho vùng chứa có bề mặt tấn công nhỏ hơn nhiều so với các hệ điều hành có mục đích
chung. Ví dụ: chúng không chứa các thư viện và trình quản lý gói cho phép hệ điều hành đa năng chạy trực tiếp
các ứng dụng cơ sở dữ liệu và máy chủ web. Tuy nhiên, mặc dù các bộ chứa cung cấp khả năng cách ly tài
nguyên ở cấp độ phần mềm mạnh mẽ, việc sử dụng hạt nhân dùng chung luôn dẫn đến bề mặt tấn công giữa các
đối tượng lớn hơn so với các trình ảo hóa, ngay cả đối với các hệ điều hành dành riêng cho bộ chứa. Nói cách
khác, mức độ cô lập được cung cấp bởi thời gian chạy của container không cao bằng mức độ được cung cấp bởi
các trình ảo hóa.
3.5.3 Lỗ hổng thành phần hệ điều hành máy chủ
Tất cả các hệ điều hành máy chủ, thậm chí cả các hệ điều hành dành riêng cho vùng chứa, đều cung cấp các
thành phần hệ thống nền tảng—ví dụ: các thư viện mật mã được sử dụng để xác thực các kết nối từ xa và các
nguyên hàm hạt nhân được sử dụng để gọi và quản lý quy trình chung. Giống như bất kỳ phần mềm nào khác, các
thành phần này có thể có lỗ hổng và do chúng tồn tại ở mức độ thấp trong kiến trúc công nghệ vùng chứa nên
chúng có thể tác động đến tất cả các vùng chứa và ứng dụng chạy trên các máy chủ này.
3.5.4 Quyền truy cập của người dùng không đúng
Các hệ điều hành dành riêng cho vùng chứa thường không được tối ưu hóa để hỗ trợ các tình huống nhiều
người dùng do việc đăng nhập tương tác của người dùng rất hiếm. Các tổ chức có thể gặp rủi ro khi người
dùng đăng nhập trực tiếp vào máy chủ để quản lý vùng chứa thay vì đi qua lớp điều phối. Quản lý trực tiếp cho
phép thực hiện các thay đổi trên phạm vi rộng đối với hệ thống và tất cả vùng chứa trên đó, đồng thời
có thể cho phép người dùng chỉ cần quản lý vùng chứa của một ứng dụng cụ thể có thể tác động đến nhiều vùng
chứa khác.
3.5.5 Giả mạo hệ thống tệp hệ điều hành máy chủ
Cấu hình vùng chứa không an toàn có thể khiến khối lượng máy chủ có nguy cơ giả mạo tệp cao hơn. Ví dụ: nếu
một vùng chứa được phép gắn các thư mục nhạy cảm trên hệ điều hành máy chủ thì vùng chứa đó có thể thay đổi
các tệp trong các thư mục đó. Những thay đổi này có thể ảnh hưởng đến tính ổn định và bảo mật của máy chủ cũng
như tất cả các vùng chứa khác chạy trên đó.
18
đ
n
b
Ất
p
cm NIST SP 800-190
4 biện pháp đối phó với những rủi ro lớn

Phần này khuyến nghị các biện pháp đối phó với những rủi ro chính được xác định trong Phần 3.
4.1 Biện pháp đối phó hình ảnh
4.1.1 Lỗ hổng hình ảnh
Cần có các công cụ và quy trình quản lý lỗ hổng dành riêng cho công nghệ container.
Các công cụ quản lý lỗ hổng truyền thống đưa ra nhiều giả định về độ bền của máy chủ và
các cơ chế và tần suất cập nhật ứng dụng về cơ bản không phù hợp với mô hình được chứa trong vùng chứa. Những
công cụ này thường không thể phát hiện các lỗ hổng trong vùng chứa, dẫn đến cảm giác an toàn sai lầm.
Các tổ chức nên sử dụng các công cụ áp dụng phương pháp xây dựng dựa trên quy trình cũng như tính chất bất biến
của vùng chứa và hình ảnh vào thiết kế của mình để mang lại kết quả đáng tin cậy và khả thi hơn. Các khía
cạnh chính của các công cụ và quy trình hiệu quả bao gồm:
1. Tích hợp với toàn bộ vòng đời của hình ảnh, từ khi bắt đầu quá trình xây dựng, đến bất kỳ cơ quan đăng
ký nào mà tổ chức đang sử dụng, cho đến thời gian chạy.
2. Khả năng hiển thị các lỗ hổng ở tất cả các lớp của hình ảnh, không chỉ lớp cơ sở của
hình ảnh mà còn cả các khung ứng dụng và phần mềm tùy chỉnh mà tổ chức đang sử dụng.
Khả năng hiển thị phải được tập trung trong toàn tổ chức và cung cấp chế độ xem báo cáo và giám sát
linh hoạt phù hợp với quy trình kinh doanh của tổ chức.
3. Thực thi theo chính sách; các tổ chức phải có thể tạo “các cổng chất lượng” ở mỗi giai đoạn của quá
trình xây dựng và triển khai để đảm bảo rằng chỉ những hình ảnh đáp ứng các chính sách về cấu
hình và lỗ hổng của tổ chức mới được phép tiến hành. Ví dụ: các tổ chức có thể định cấu hình
quy tắc trong quá trình xây dựng để ngăn chặn sự tiến triển của các hình ảnh có lỗ hổng bảo mật có
xếp hạng Hệ thống chấm điểm lỗ hổng bảo mật chung (CVSS) [18] trên ngưỡng đã chọn.
4.1.2 Lỗi cấu hình hình ảnh
Các tổ chức nên áp dụng các công cụ và quy trình để xác thực và thực thi việc tuân thủ các biện pháp thực
hành tốt nhất về cấu hình bảo mật. Ví dụ: hình ảnh phải được định cấu hình để chạy với tư cách người dùng
không có đặc quyền. Các công cụ và quy trình nên được áp dụng bao gồm:
1. Xác thực cài đặt cấu hình hình ảnh, bao gồm đề xuất của nhà cung cấp và các phương pháp hay nhất của
bên thứ ba.
2. Báo cáo và giám sát tập trung, liên tục, liên tục về trạng thái tuân thủ hình ảnh để xác
định các điểm yếu và rủi ro ở cấp tổ chức.
3. Thực thi các yêu cầu tuân thủ bằng cách tùy ý ngăn chặn việc chạy các hình ảnh không tuân thủ.
4. Chỉ sử dụng các lớp cơ sở từ các nguồn đáng tin cậy, cập nhật thường xuyên các lớp cơ sở và
lựa chọn các lớp cơ sở từ các công nghệ tối giản như Alpine Linux và Windows Nano Server để giảm diện
tích bề mặt tấn công.
19
đ
n
b
Ất
p
Khuyến nghị cuối cùng cho cấu hình hình ảnh là không bao giờ được bật SSH và các công cụ quản trị từ xa khác
được thiết kế để cung cấp shell từ xa cho máy chủ trong vùng chứa.
Các thùng chứa phải được chạy theo cách không thể thay đổi để thu được lợi ích bảo mật lớn nhất từ việc sử
dụng chúng. Việc cho phép truy cập từ xa vào chúng thông qua các công cụ này ngụ ý mức độ thay đổi vi phạm nguyên
tắc này và khiến chúng có nguy cơ bị tấn công dựa trên mạng cao hơn. Thay vào đó, tất cả việc quản lý
vùng chứa từ xa phải được thực hiện thông qua API thời gian chạy của vùng chứa. API này có thể được truy cập
thông qua các công cụ điều phối hoặc bằng cách tạo các phiên shell từ xa tới máy chủ mà vùng chứa đang chạy
trên đó.
4.1.3 Phần mềm độc hại nhúng
Các tổ chức nên liên tục theo dõi tất cả các hình ảnh để phát hiện phần mềm độc hại được nhúng. Việc giám sát
các quy trình nên bao gồm việc sử dụng các bộ chữ ký phần mềm độc hại và chẩn đoán phát hiện hành vi chủ yếu
dựa trên các cuộc tấn công “trong tự nhiên” thực tế.
4.1.4 Bí mật văn bản rõ ràng được nhúng
Bí mật phải được lưu trữ bên ngoài hình ảnh và được cung cấp động trong thời gian chạy nếu cần. Hầu hết các bộ
điều phối, chẳng hạn như Docker Swarm và Kubernetes, đều bao gồm tính năng quản lý bí mật riêng.
Những bộ điều phối này không chỉ cung cấp khả năng lưu trữ bí mật an toàn và đưa các bí mật 'đúng lúc' vào
các vùng chứa mà còn giúp việc tích hợp quản lý bí mật vào quy trình xây dựng và triển khai trở nên đơn
giản hơn nhiều. Ví dụ: một tổ chức có thể sử dụng các công cụ này để cung cấp chuỗi kết nối cơ sở dữ liệu một
cách an toàn vào vùng chứa ứng dụng web. Người điều phối có thể đảm bảo rằng chỉ vùng chứa ứng dụng web mới có
quyền truy cập vào bí mật này, bí mật đó không được lưu vào đĩa và bất cứ khi nào ứng dụng web được triển
khai, bí mật sẽ được cung cấp vào đó.
Các tổ chức cũng có thể tích hợp việc triển khai vùng chứa của họ với các hệ thống quản lý bí mật doanh
nghiệp hiện có đã được sử dụng để lưu trữ bí mật trong môi trường không có vùng chứa.
Các công cụ này thường cung cấp API để truy xuất bí mật một cách an toàn khi các vùng chứa được triển khai, giúp
loại bỏ nhu cầu lưu giữ chúng trong hình ảnh.
Bất kể công cụ nào được chọn, các tổ chức phải đảm bảo rằng bí mật chỉ được cung cấp cho các vùng chứa cụ thể
cần đến chúng, dựa trên cài đặt được xác định trước và do quản trị viên kiểm soát,
và các bí mật đó luôn được mã hóa khi lưu trữ và truyền đi bằng cách sử dụng Quy trình xử lý thông tin liên bang
Tiêu chuẩn (FIPS) 140 thuật toán mã hóa được phê duyệt5 có trong mật mã được xác thực
mô-đun.
4.1.5 Sử dụng hình ảnh không đáng tin cậy
Các tổ chức nên duy trì một bộ hình ảnh và sổ đăng ký đáng tin cậy, đồng thời đảm bảo rằng chỉ những hình ảnh từ
bộ này mới được phép chạy trong môi trường của họ, từ đó giảm thiểu nguy cơ triển khai các thành phần không
đáng tin cậy hoặc độc hại.
Để giảm thiểu những rủi ro này, các tổ chức nên áp dụng cách tiếp cận đa tầng bao gồm:
5
Để biết thêm thông tin về việc triển khai mật mã được NIST xác thực, hãy xem trang Chương trình xác thực mô-đun mật mã
(CMVP) tại https://csrc.nist.gov/groups/STM/cmvp/.
20
đ
n
b
Ất
p
• Khả năng kiểm soát tập trung chính xác những hình ảnh và đăng ký nào được tin cậy trong
môi trường;
• Nhận dạng riêng biệt từng hình ảnh bằng chữ ký mật mã, sử dụng chữ ký được NIST xác thực
thực hiện6 ;
• Thực thi để đảm bảo rằng tất cả các máy chủ trong môi trường chỉ chạy hình ảnh từ những
danh sách được phê duyệt;
• Xác thực chữ ký hình ảnh trước khi thực thi hình ảnh để đảm bảo hình ảnh được tin cậy
nguồn và không bị giả mạo; Và
• Giám sát và bảo trì liên tục các kho lưu trữ này để đảm bảo hình ảnh bên trong chúng được duy trì và cập
nhật khi các lỗ hổng và yêu cầu cấu hình thay đổi.
4.2 Biện pháp đối phó với việc đăng ký
4.2.1 Kết nối tới cơ quan đăng ký không an toàn
Các tổ chức nên định cấu hình các công cụ phát triển, bộ điều phối và thời gian chạy vùng chứa của mình để chỉ
kết nối với các cơ quan đăng ký qua các kênh được mã hóa. Các bước cụ thể sẽ khác nhau giữa các công cụ nhưng mục
tiêu chính là đảm bảo rằng tất cả dữ liệu được đẩy đến và lấy từ sổ đăng ký diễn ra giữa các điểm cuối đáng
tin cậy và được mã hóa trong quá trình truyền.
4.2.2 Hình ảnh cũ trong sổ đăng ký
Rủi ro khi sử dụng hình ảnh cũ có thể được giảm thiểu thông qua hai phương pháp chính. Đầu tiên, các
tổ chức có thể lược bỏ các sổ đăng ký chứa những hình ảnh không an toàn, dễ bị tổn thương không còn được sử dụng nữa.
Quá trình này có thể được tự động hóa dựa trên các yếu tố kích hoạt thời gian và nhãn liên quan đến hình ảnh.
Thứ hai, thực tiễn vận hành nên nhấn mạnh việc truy cập hình ảnh bằng cách sử dụng các tên bất biến chỉ định
các phiên bản hình ảnh riêng biệt sẽ được sử dụng. Ví dụ: thay vì định cấu hình tác vụ triển khai
để sử dụng hình ảnh có tên my-app, hãy định cấu hình nó để triển khai các phiên bản cụ thể của hình ảnh, chẳng
hạn như my-app:2.3 và my-app:2.4 để đảm bảo rằng các phiên bản cụ thể, tốt đã biết của hình ảnh được triển
khai như một phần của mỗi công việc.
Một tùy chọn khác là sử dụng thẻ “mới nhất” cho hình ảnh và tham chiếu thẻ này trong tự động hóa triển
khai. Tuy nhiên, vì thẻ này chỉ là nhãn gắn liền với hình ảnh và không đảm bảo độ mới, các tổ chức nên thận
trọng để không quá tin tưởng vào nó. Bất kể tổ chức chọn sử dụng tên riêng biệt hay sử dụng thẻ “mới nhất”,
điều quan trọng là phải thực hiện các quy trình để đảm bảo rằng quá trình tự động hóa đang sử dụng tên duy nhất
gần đây nhất hoặc hình ảnh được gắn thẻ “mới nhất” thực sự làm như vậy đại diện cho các phiên bản cập nhật
nhất.
4.2.3 Hạn chế xác thực và ủy quyền không đầy đủ
Tất cả quyền truy cập vào sổ đăng ký có chứa hình ảnh độc quyền hoặc nhạy cảm đều phải yêu cầu xác thực.
Mọi quyền ghi vào sổ đăng ký đều phải yêu cầu xác thực để đảm bảo rằng chỉ có hình ảnh từ các thực thể đáng
tin cậy mới có thể được thêm vào sổ đăng ký. Ví dụ: chỉ cho phép các nhà phát triển đẩy hình ảnh đến các
kho lưu trữ cụ thể mà họ chịu trách nhiệm, thay vì có thể cập nhật bất kỳ kho lưu trữ nào.
6
Để biết thêm thông tin về việc triển khai mật mã được NIST xác thực, hãy xem trang Chương trình xác thực mô-đun mật mã
(CMVP) tại https://csrc.nist.gov/projects/cryptographic-module-validation-program.
21
đ
n
b
Ất
p
Các tổ chức nên xem xét việc liên kết với các tài khoản hiện có, chẳng hạn như dịch vụ thư mục của chính họ
hoặc của nhà cung cấp dịch vụ đám mây để tận dụng các biện pháp kiểm soát bảo mật đã có sẵn cho các tài
khoản đó. Tất cả quyền truy cập ghi vào sổ đăng ký phải được kiểm tra và mọi hành động đọc đối với hình
ảnh nhạy cảm cũng phải được ghi lại tương tự.
Cơ quan đăng ký cũng cung cấp cơ hội áp dụng các biện pháp kiểm soát ủy quyền theo ngữ cảnh cho các hành động.
Ví dụ: các tổ chức có thể định cấu hình quy trình tích hợp liên tục của mình để cho phép nhân viên có thẩm quyền
ký các hình ảnh và chỉ được đưa vào cơ quan đăng ký sau khi họ đã vượt qua quá trình quét lỗ hổng và đánh giá
tuân thủ. Các tổ chức nên tích hợp các lần quét tự động này vào quy trình của mình để ngăn chặn việc quảng bá
và triển khai các hình ảnh dễ bị tấn công hoặc bị định cấu hình sai.
4.3 Biện pháp đối phó của người điều phối
4.3.1 Truy cập quản trị không giới hạn
Đặc biệt do phạm vi kiểm soát trên phạm vi rộng, người điều phối nên sử dụng mô hình truy cập đặc quyền
tối thiểu trong đó người dùng chỉ được cấp khả năng thực hiện các hành động cụ thể trên máy chủ, vùng chứa và
hình ảnh cụ thể mà vai trò công việc của họ yêu cầu. Ví dụ: các thành viên của nhóm thử nghiệm chỉ được cấp quyền
truy cập vào các hình ảnh được sử dụng trong thử nghiệm và máy chủ được sử dụng để chạy chúng, đồng thời chỉ có
thể thao tác với các vùng chứa mà họ đã tạo. Các thành viên trong nhóm thử nghiệm phải có quyền hạn chế
hoặc không có quyền truy cập vào các thùng chứa được sử dụng trong sản xuất.
4.3.2 Truy cập trái phép
Việc truy cập vào các tài khoản quản trị trên toàn cụm cần được kiểm soát chặt chẽ vì những tài khoản này
cung cấp khả năng ảnh hưởng đến tất cả các tài nguyên trong môi trường. Các tổ chức nên sử dụng các
phương pháp xác thực mạnh, chẳng hạn như yêu cầu xác thực đa yếu tố thay vì chỉ dùng mật khẩu.
Các tổ chức nên triển khai đăng nhập một lần vào các hệ thống thư mục hiện có nếu có.
Đăng nhập một lần giúp đơn giản hóa trải nghiệm xác thực của người điều phối, giúp người dùng dễ dàng sử dụng
thông tin xác thực mạnh hơn và tập trung kiểm tra quyền truy cập, giúp việc phát hiện bất thường hiệu
quả hơn.
Các phương pháp truyền thống để mã hóa dữ liệu ở trạng thái lưu trữ thường liên quan đến việc sử dụng các khả
năng dựa trên máy chủ có thể không tương thích với các bộ chứa. Do đó, các tổ chức nên sử dụng các công cụ
mã hóa dữ liệu được sử dụng với các bộ chứa cho phép truy cập dữ liệu đúng cách từ các bộ chứa bất kể chúng
đang chạy trên nút nào. Các công cụ mã hóa như vậy phải cung cấp các rào cản tương tự đối với việc truy
cập trái phép và giả mạo, sử dụng các phương pháp mã hóa tương tự như các phương pháp được xác định trong NIST
SP 800-111 [19].
4.3.3 Lưu lượng mạng liên vùng bị phân tách kém
Bộ điều phối phải được cấu hình để phân tách lưu lượng mạng thành các mạng ảo riêng biệt theo mức độ nhạy cảm.
Mặc dù cũng có thể phân đoạn theo từng ứng dụng, nhưng đối với hầu hết các tổ chức và trường hợp sử dụng,
chỉ cần xác định mạng theo mức độ nhạy cảm là đủ để giảm thiểu rủi ro với mức độ phức tạp có thể quản lý được.
Ví dụ: các ứng dụng công khai có thể chia sẻ mạng ảo,
22
đ
n
bt
p
các ứng dụng nội bộ có thể sử dụng ứng dụng khác và giao tiếp giữa hai ứng dụng này sẽ diễn ra thông qua
một số ít giao diện được xác định rõ ràng.
4.3.4 Trộn các mức độ nhạy cảm của khối lượng công việc
Người điều phối phải được cấu hình để tách biệt việc triển khai với các nhóm máy chủ cụ thể theo mức độ
Ấ
nhạy cảm. Cách tiếp cận cụ thể để triển khai điều này khác nhau tùy thuộc vào bộ điều phối đang sử dụng,
nhưng mô hình chung là xác định các quy tắc ngăn không cho khối lượng công việc có độ nhạy cao được đặt trên
cùng một máy chủ với những khối lượng công việc có độ nhạy thấp hơn. Điều này có thể được thực hiện
thông qua việc sử dụng 'ghim' máy chủ trong bộ điều phối hoặc thậm chí đơn giản bằng cách có các cụm
riêng biệt, được quản lý riêng cho từng mức độ nhạy cảm.
Mặc dù hầu hết các môi trường thời gian chạy của bộ chứa thực hiện công việc cách ly các bộ chứa với nhau và
với hệ điều hành máy chủ một cách hiệu quả, nhưng trong một số trường hợp, việc chạy các ứng dụng có mức
độ nhạy cảm khác nhau cùng nhau trên cùng một hệ điều hành máy chủ có thể là một rủi ro không cần thiết.
Việc phân đoạn vùng chứa theo mục đích, độ nhạy cảm và trạng thái mối đe dọa sẽ cung cấp thêm khả năng
phòng vệ theo chiều sâu. Các khái niệm như phân tầng ứng dụng, phân đoạn mạng và máy chủ cần
được xem xét khi lập kế hoạch triển khai ứng dụng. Ví dụ: giả sử máy chủ đang chạy vùng chứa cho cả cơ sở dữ
liệu tài chính và blog công khai. Mặc dù thông thường thời gian chạy vùng chứa sẽ cách ly các môi
trường này với nhau một cách hiệu quả, nhưng các nhóm DevOps cũng có trách nhiệm chung để mỗi ứng dụng
vận hành chúng một cách an toàn và loại bỏ rủi ro không cần thiết. Nếu ứng dụng blog được
bị kẻ tấn công xâm phạm, sẽ có ít lớp phòng thủ hơn để bảo vệ cơ sở dữ liệu nếu hai ứng dụng đang chạy trên
cùng một máy chủ.
Vì vậy, cách tốt nhất là nhóm các thùng chứa lại với nhau theo độ nhạy tương đối và đảm bảo rằng một hạt
nhân máy chủ nhất định chỉ chạy các thùng chứa có một mức độ nhạy duy nhất. Phân đoạn này có thể được
cung cấp bằng cách sử dụng nhiều máy chủ vật lý, nhưng các trình ảo hóa hiện đại cũng cung cấp khả năng
cách ly đủ mạnh để giảm thiểu những rủi ro này một cách hiệu quả. Từ ví dụ trước, điều này có thể có nghĩa
là tổ chức có hai mức độ nhạy cảm đối với vùng chứa của họ. Một dành cho các ứng dụng tài chính và cơ
sở dữ liệu được bao gồm trong nhóm đó. Nhóm còn lại dành cho ứng dụng web và blog được bao gồm trong
nhóm đó. Khi đó, tổ chức sẽ có hai nhóm máy ảo, mỗi nhóm sẽ lưu trữ các vùng chứa ở một mức độ nghiêm trọng
duy nhất. Ví dụ: máy chủ có tên vm-financial có thể lưu trữ các vùng chứa chạy cơ sở dữ liệu tài chính cũng
như phần mềm báo cáo thuế, trong khi máy chủ có tên vm-web có thể lưu trữ blog và trang web công cộng.
Bằng cách phân chia các container theo cách này, kẻ tấn công sẽ gặp khó khăn hơn nhiều.
xâm phạm một trong các phân khúc để mở rộng sự xâm phạm đó sang các phân khúc khác. Kẻ tấn công xâm
phạm một máy chủ sẽ bị hạn chế khả năng thực hiện trinh sát và tấn công vào các vùng chứa khác có mức độ
nhạy cảm tương tự và không có bất kỳ quyền truy cập bổ sung nào
vượt ra ngoài nó. Cách tiếp cận này cũng đảm bảo rằng mọi dữ liệu còn sót lại, chẳng hạn như bộ đệm
hoặc ổ đĩa cục bộ được gắn cho tệp tạm thời, vẫn nằm trong vùng bảo mật của dữ liệu. Từ ví dụ trước,
việc phân vùng này sẽ đảm bảo rằng mọi dữ liệu tài chính được lưu trữ cục bộ và còn sót lại sau
khi chấm dứt vùng chứa sẽ không bao giờ có sẵn trên máy chủ chạy ứng dụng ở mức độ nhạy cảm thấp hơn.
Trong môi trường quy mô lớn hơn với hàng trăm máy chủ và hàng nghìn vùng chứa, phân đoạn này
phải được tự động hóa để có thể vận hành thực tế. May mắn thay, các nền tảng điều phối phổ biến
thường bao gồm một số khái niệm về khả năng nhóm các ứng dụng lại với nhau và
23
đ
n
b
Ất
p
các công cụ bảo mật vùng chứa có thể sử dụng các thuộc tính như tên và nhãn vùng chứa để thực thi các chính
sách bảo mật trên chúng. Trong những môi trường này, các lớp bảo vệ bổ sung theo chiều sâu ngoài khả năng cách
ly máy chủ đơn giản cũng có thể thúc đẩy sự phân khúc này. Ví dụ: một tổ chức có thể triển khai các vùng hoặc
mạng lưu trữ riêng biệt để không chỉ cách ly các vùng chứa này trong bộ ảo hóa mà còn để cách ly lưu lượng
truy cập mạng của họ một cách riêng biệt hơn sao cho lưu lượng truy cập cho các ứng dụng ở một mức độ nhạy
cảm tách biệt với lưu lượng truy cập ở các mức độ nhạy cảm khác.
4.3.5 Sự tin cậy của nút soạn thảo
Nền tảng điều phối phải được định cấu hình để cung cấp các tính năng tạo môi trường an toàn cho
tất cả các ứng dụng mà chúng chạy. Người điều phối phải đảm bảo rằng các nút được an toàn
được đưa vào cụm, có danh tính liên tục trong suốt vòng đời của chúng và cũng có thể cung cấp bản kiểm
kê chính xác về các nút và trạng thái kết nối của chúng. Các tổ chức nên đảm bảo rằng các nền tảng điều phối
được thiết kế đặc biệt để có khả năng phục hồi trước sự xâm phạm của các nút riêng lẻ mà không ảnh hưởng đến
tính bảo mật chung của cụm. Nút bị xâm nhập phải có khả năng được cách ly và xóa khỏi cụm mà không làm gián
đoạn hoặc làm suy giảm hoạt động tổng thể của cụm. Cuối cùng, các tổ chức nên chọn các nhà điều phối cung cấp
các kết nối mạng được xác thực lẫn nhau giữa các thành viên trong cụm và mã hóa đầu cuối của lưu
lượng truy cập trong cụm. Do tính di động của vùng chứa, nhiều hoạt động triển khai có thể xảy ra trên các
mạng mà các tổ chức không trực tiếp kiểm soát, do đó, chế độ bảo mật theo mặc định đặc biệt quan trọng đối
với trường hợp này.
4.4 Biện pháp đối phó với container
4.4.1 Lỗ hổng trong phần mềm thời gian chạy
Thời gian chạy của vùng chứa phải được theo dõi cẩn thận để phát hiện các lỗ hổng và khi phát hiện sự cố,
chúng phải được khắc phục nhanh chóng. Thời gian chạy dễ bị tấn công sẽ khiến tất cả các vùng chứa mà
nó hỗ trợ, cũng như chính máy chủ, gặp rủi ro tiềm ẩn đáng kể. Các tổ chức nên sử dụng các công cụ để tìm kiếm
lỗ hổng Lỗ hổng và Lỗ hổng phổ biến (CVE) trong thời gian chạy được triển khai, để nâng cấp mọi phiên
bản có nguy cơ và để đảm bảo rằng người điều phối chỉ cho phép triển khai trong thời gian chạy
được duy trì đúng cách.
4.4.2 Truy cập mạng không giới hạn từ container
Các tổ chức nên kiểm soát lưu lượng truy cập mạng đầu ra được gửi bởi container. Ở mức tối thiểu, các biện
pháp kiểm soát này phải được áp dụng ở biên giới mạng, đảm bảo các bộ chứa không thể gửi lưu lượng truy cập
qua các mạng có mức độ nhạy cảm khác nhau, chẳng hạn như từ môi trường lưu trữ dữ liệu an toàn trên internet,
tương tự như các mẫu được sử dụng cho kiến trúc truyền thống. Tuy nhiên, mô hình mạng ảo hóa của lưu lượng liên
container đặt ra một thách thức bổ sung.
Vì các bộ chứa được triển khai trên nhiều máy chủ thường giao tiếp qua mạng ảo được mã hóa nên các
thiết bị mạng truyền thống thường không nhận ra lưu lượng này. Ngoài ra, các vùng chứa thường được gán
địa chỉ IP động tự động khi được người điều phối triển khai và các địa chỉ này thay đổi liên tục khi
ứng dụng được điều chỉnh tỷ lệ và cân bằng tải.
Vì vậy, lý tưởng nhất là các tổ chức nên sử dụng kết hợp các thiết bị cấp mạng hiện có và tính năng lọc
mạng nhận biết ứng dụng hơn. Các công cụ nhận biết ứng dụng không chỉ có thể xem lưu lượng truy cập
giữa các vùng chứa mà còn có thể tự động tạo các quy tắc được sử dụng để lọc lưu lượng truy cập này dựa trên
24
đ
n
b
Ất
p
đặc điểm cụ thể của ứng dụng đang chạy trong vùng chứa. Việc quản lý quy tắc động này rất quan trọng do quy mô và tốc
độ thay đổi của các ứng dụng được chứa trong bộ chứa cũng như cấu trúc liên kết mạng phù du của chúng.
Cụ thể, các công cụ nhận biết ứng dụng phải cung cấp các khả năng sau:
• Tự động xác định các bề mặt mạng container thích hợp, bao gồm cả hai
cổng vào và các ràng buộc cổng xử lý;
• Phát hiện luồng lưu lượng giữa các container và các thực thể mạng khác, trên cả hai
giao thông 'trên dây' và giao thông được đóng gói; Và
• Phát hiện các điểm bất thường của mạng, chẳng hạn như các luồng lưu lượng truy cập không mong muốn trong
mạng của tổ chức, quét cổng hoặc truy cập ra bên ngoài tới các điểm đến nguy hiểm tiềm tàng.
4.4.3 Cấu hình thời gian chạy vùng chứa không an toàn
Các tổ chức nên tự động hóa việc tuân thủ các tiêu chuẩn cấu hình thời gian chạy vùng chứa.
Hướng dẫn triển khai kỹ thuật được ghi lại, chẳng hạn như Trung tâm điểm chuẩn Docker bảo mật Internet [20], cung cấp
chi tiết về các tùy chọn và cài đặt được đề xuất, nhưng việc vận hành hướng dẫn này phụ thuộc vào tự động hóa. Các tổ
chức có thể sử dụng nhiều công cụ khác nhau để “quét” và đánh giá sự tuân thủ của họ tại một thời điểm, nhưng những
cách tiếp cận như vậy không có quy mô lớn. Thay vào đó, tổ chức nên sử dụng các công cụ hoặc quy trình liên tục
đánh giá cài đặt cấu hình trên toàn môi trường và tích cực thực thi chúng.
Ngoài ra, các công nghệ kiểm soát truy cập bắt buộc (MAC) như SELinux [21] và AppArmor [22] cung cấp khả năng kiểm
soát và cách ly nâng cao cho các container chạy hệ điều hành Linux. Ví dụ: những công nghệ này có thể được sử dụng
để cung cấp phân đoạn bổ sung và đảm bảo rằng các bộ chứa chỉ có thể truy cập vào các đường dẫn tệp, quy trình và ổ
cắm mạng cụ thể, hạn chế hơn nữa khả năng của một bộ chứa bị xâm nhập tác động đến máy chủ hoặc các bộ chứa
khác.
Công nghệ MAC cung cấp sự bảo vệ ở lớp hệ điều hành máy chủ, đảm bảo rằng chỉ những tệp cụ thể,
đường dẫn và quy trình có thể truy cập được đối với các ứng dụng được chứa. Các tổ chức được khuyến khích sử dụng
công nghệ MAC do hệ điều hành máy chủ của họ cung cấp trong tất cả các hoạt động triển khai vùng chứa.
Cấu hình điện toán an toàn (seccomp)7 là một cơ chế khác có thể được sử dụng để hạn chế các vùng chứa khả năng cấp hệ
thống được phân bổ trong thời gian chạy. Thời gian chạy vùng chứa phổ biến như Docker bao gồm các cấu hình seccomp
mặc định loại bỏ các lệnh gọi hệ thống không an toàn và thường không cần thiết cho hoạt động của vùng chứa. Ngoài
ra, hồ sơ tùy chỉnh có thể được tạo và chuyển đến thời gian chạy của vùng chứa để hạn chế hơn nữa khả năng của chúng.
Ở mức tối thiểu, các tổ chức phải đảm bảo rằng các vùng chứa được chạy với cấu hình mặc định do thời gian chạy của
chúng cung cấp và nên cân nhắc việc sử dụng các cấu hình bổ sung cho các ứng dụng có rủi ro cao.
4.4.4 Lỗ hổng ứng dụng
Các quy trình và công cụ phát hiện xâm nhập dựa trên máy chủ hiện tại thường không thể phát hiện và ngăn chặn các cuộc
tấn công trong vùng chứa do kiến trúc kỹ thuật và thực tiễn vận hành khác nhau
7
Để biết thêm thông tin về seccomp, hãy xem https://www.kernel.org/doc/Documentation/prctl/seccomp_filter.txt.
25
đ
n
b
Ất
p
đã thảo luận trước đó. Các tổ chức nên triển khai các công cụ bổ sung có khả năng nhận biết vùng chứa và được
thiết kế để hoạt động ở quy mô và tốc độ thay đổi thường thấy với vùng chứa. Những công cụ này có thể tự động
lập hồ sơ cho các ứng dụng được đóng gói bằng cách sử dụng phương pháp học tập hành vi và xây dựng hồ sơ bảo
mật cho chúng để giảm thiểu sự tương tác của con người. Sau đó, những cấu hình này sẽ có thể ngăn chặn và phát
hiện các điểm bất thường trong thời gian chạy, bao gồm các sự kiện như:
• Việc thực thi quy trình không hợp lệ hoặc không mong muốn,
• Cuộc gọi hệ thống không hợp lệ hoặc không mong muốn,
• Thay đổi các tệp cấu hình và tệp nhị phân được bảo vệ,
• Ghi vào các vị trí và loại tệp không mong muốn,
• Tạo các trình nghe mạng bất ngờ,
• Lưu lượng được gửi đến các điểm đến mạng không mong muốn và
• Lưu trữ hoặc thực thi phần mềm độc hại.
Các thùng chứa cũng phải được chạy với hệ thống tệp gốc của chúng ở chế độ chỉ đọc. Cách tiếp cận này tách
biệt việc ghi vào các thư mục được xác định cụ thể, sau đó có thể được giám sát dễ dàng hơn bằng các công cụ
nói trên. Hơn nữa, việc sử dụng hệ thống tệp chỉ đọc giúp các vùng chứa có khả năng chống thỏa hiệp cao hơn vì
mọi hoạt động giả mạo đều được cách ly ở các vị trí cụ thể này và có thể dễ dàng tách khỏi phần còn lại của
ứng dụng.
4.4.5 Thùng chứa giả mạo
Các tổ chức nên thiết lập các môi trường riêng biệt để phát triển, thử nghiệm, sản xuất và các tình huống
khác, mỗi môi trường có các biện pháp kiểm soát cụ thể để cung cấp khả năng kiểm soát truy cập dựa trên vai
trò cho các hoạt động quản lý và triển khai vùng chứa. Tất cả việc tạo vùng chứa phải được liên kết với
danh tính người dùng cá nhân và được ghi lại để cung cấp dấu vết kiểm tra hoạt động rõ ràng. Hơn
nữa, các tổ chức được khuyến khích sử dụng các công cụ bảo mật có thể thực thi các yêu cầu cơ bản về quản lý
và tuân thủ lỗ hổng trước khi cho phép chạy hình ảnh.
4.5 Biện pháp đối phó với hệ điều hành máy chủ
4.5.1 Bề mặt tấn công lớn
Đối với các tổ chức sử dụng hệ điều hành dành riêng cho vùng chứa, các mối đe dọa thường bắt đầu ở mức tối
thiểu hơn vì hệ điều hành được thiết kế đặc biệt để lưu trữ vùng chứa và bị vô hiệu hóa các dịch vụ cũng
như chức năng khác. Hơn nữa, vì các hệ điều hành được tối ưu hóa này được thiết kế đặc biệt để lưu trữ các
vùng chứa nên chúng thường có hệ thống tệp chỉ đọc và sử dụng các phương pháp tăng cường độ cứng khác theo
mặc định. Bất cứ khi nào có thể, các tổ chức nên sử dụng các hệ điều hành tối giản này để giảm thiểu các bề
mặt tấn công và giảm thiểu các rủi ro điển hình cũng như các hoạt động tăng cường liên quan đến các hệ điều hành có
mục đích chung.
Các tổ chức không thể sử dụng hệ điều hành dành riêng cho vùng chứa nên làm theo hướng dẫn trong NIST SP
800-123, Hướng dẫn về bảo mật máy chủ chung [23] để giảm bề mặt tấn công của máy chủ của họ nhiều nhất có
thể. Ví dụ: máy chủ chạy vùng chứa chỉ được chạy vùng chứa và không chạy các ứng dụng khác, như máy chủ web hoặc
cơ sở dữ liệu, bên ngoài vùng chứa. Hệ điều hành máy chủ không nên chạy các dịch vụ hệ thống không cần thiết,
chẳng hạn như bộ đệm in, làm tăng diện tích bề mặt tấn công và vá lỗi. Cuối cùng, máy chủ phải được quét liên tục
để tìm lỗ hổng và cập nhật được áp dụng
26
đ
n
bt
p
một cách nhanh chóng, không chỉ đối với thời gian chạy của bộ chứa mà còn đối với các thành phần cấp thấp hơn như
hạt nhân mà bộ chứa dựa vào để vận hành an toàn, được phân chia theo từng ngăn.
4.5.2 Hạt nhân dùng chung
Ngoài việc nhóm khối lượng công việc trong bộ chứa trên các máy chủ theo mức độ nhạy cảm, các tổ chức không nên kết
Ấ
hợp khối lượng công việc trong bộ chứa và không trong bộ chứa trên cùng một phiên bản máy chủ. Ví dụ: nếu máy chủ
đang chạy vùng chứa máy chủ web thì máy chủ đó cũng không nên chạy máy chủ web (hoặc bất kỳ ứng dụng nào khác) như
một thành phần được cài đặt thường xuyên trực tiếp trong Hệ điều hành máy chủ. Việc tách biệt khối lượng công việc
trong bộ chứa với các máy chủ dành riêng cho bộ chứa giúp việc áp dụng các biện pháp đối phó và biện pháp bảo
vệ được tối ưu hóa để bảo vệ bộ chứa trở nên đơn giản và an toàn hơn.
4.5.3 Lỗ hổng thành phần hệ điều hành máy chủ
Các tổ chức nên triển khai các phương pháp và công cụ quản lý để xác thực phiên bản của các thành phần được cung
cấp cho chức năng và quản lý hệ điều hành cơ sở. Mặc dù các hệ điều hành dành riêng cho vùng chứa có bộ
thành phần tối thiểu hơn nhiều so với các hệ điều hành có mục đích chung nhưng chúng vẫn có lỗ hổng và vẫn cần được
khắc phục. Các tổ chức nên sử dụng các công cụ do nhà cung cấp HĐH hoặc các tổ chức đáng tin cậy khác cung cấp để
thường xuyên kiểm tra và áp dụng các bản cập nhật cho tất cả các thành phần phần mềm được sử dụng trong HĐH.
Hệ điều hành phải được cập nhật không chỉ với các bản cập nhật bảo mật mà còn cả các bản cập nhật thành phần
mới nhất do nhà cung cấp khuyến nghị. Điều này đặc biệt quan trọng đối với các thành phần thời gian chạy kernel
và container vì các bản phát hành mới hơn của các thành phần này thường bổ sung thêm các tính năng và biện pháp
bảo vệ bảo mật ngoài việc chỉ sửa các lỗ hổng. Một số tổ chức có thể chọn chỉ triển khai lại các phiên bản hệ
điều hành mới với các bản cập nhật cần thiết thay vì cập nhật các hệ thống hiện có. Cách tiếp cận này cũng có giá
trị, mặc dù nó thường đòi hỏi các hoạt động vận hành phức tạp hơn.
Hệ điều hành máy chủ phải được vận hành theo cách bất biến, không có dữ liệu hoặc trạng thái được lưu trữ duy nhất
và liên tục trên máy chủ cũng như không có sự phụ thuộc cấp ứng dụng nào do máy chủ cung cấp. Thay vào đó, tất cả
các thành phần và phần phụ thuộc của ứng dụng phải được đóng gói và triển khai trong vùng chứa. Điều này cho phép
máy chủ được vận hành theo cách gần như không trạng thái với bề mặt tấn công giảm đáng kể.
Ngoài ra, nó còn cung cấp một cách đáng tin cậy hơn để xác định các điểm bất thường và sai lệch cấu hình.
4.5.4 Quyền truy cập của người dùng không đúng
Mặc dù hầu hết việc triển khai vùng chứa đều dựa vào người điều phối để phân phối công việc trên các máy
chủ, nhưng các tổ chức vẫn phải đảm bảo rằng tất cả hoạt động xác thực đối với hệ điều hành đều được kiểm tra, các
hoạt động đăng nhập bất thường đều được giám sát và mọi hoạt động leo thang để thực hiện các hoạt động đặc quyền đều
được ghi lại. Điều này giúp có thể xác định các kiểu truy cập bất thường, chẳng hạn như một cá nhân đăng nhập
trực tiếp vào máy chủ và chạy các lệnh đặc quyền để thao tác vùng chứa.
4.5.5 Giả mạo hệ thống tập tin máy chủ
Đảm bảo rằng các vùng chứa được chạy với nhóm quyền hệ thống tệp tối thiểu cần thiết. Rất hiếm khi các thùng
chứa gắn hệ thống tệp cục bộ trên máy chủ. Thay vào đó, bất kỳ thay đổi tệp nào mà bộ chứa cần lưu vào đĩa
phải được thực hiện trong các ổ lưu trữ được phân bổ cụ thể cho mục đích này. Trong mọi trường hợp, bộ chứa không
thể gắn các thư mục nhạy cảm vào hệ thống tệp của máy chủ, đặc biệt là những thư mục chứa cài đặt cấu hình cho hệ
điều hành.
27
đ
n
bt
p
Các tổ chức nên sử dụng các công cụ có thể giám sát những thư mục nào đang được gắn vào các vùng chứa và
ngăn chặn việc triển khai các vùng chứa vi phạm các chính sách này.
4.6 Biện pháp đối phó phần cứng
Bảo mật dựa trên phần mềm thường xuyên bị đánh bại, như đã được thừa nhận trong NIST SP 800-164 [24]. NIST xác định các
Ấ
yêu cầu tính toán đáng tin cậy trong NIST SP 800-147 [25], 800-155 [26] và 800-164.
Đối với NIST, “đáng tin cậy” có nghĩa là nền tảng hoạt động như mong đợi: kho phần mềm chính xác, cài đặt cấu hình và
kiểm soát bảo mật được đặt đúng chỗ và hoạt động như bình thường, v.v. “Đáng tin cậy” cũng có nghĩa là không có
người nào trái phép giả mạo phần mềm hoặc cấu hình của nó trên máy chủ. Nguồn gốc của sự tin cậy phần cứng
không phải là một khái niệm chỉ dành riêng cho vùng chứa, nhưng các công cụ bảo mật và quản lý vùng chứa có thể
tận dụng chứng thực cho phần còn lại của kiến trúc công nghệ vùng chứa để đảm bảo vùng chứa đang được chạy
trong môi trường an toàn.
Cách hiện có để cung cấp khả năng tính toán đáng tin cậy là:
1. Đo lường dữ liệu chương trình cơ sở, phần mềm và cấu hình trước khi nó được thực thi bằng Root của
Độ tin cậy để đo lường (RTM).
2. Lưu trữ các phép đo đó trong thư mục gốc phần cứng tin cậy, giống như mô-đun nền tảng đáng tin cậy
(TPM).
3. Xác nhận rằng các phép đo hiện tại khớp với các phép đo dự kiến. Nếu vậy thì có thể
đã chứng thực rằng nền tảng này có thể được tin cậy để hoạt động như mong đợi.
Các thiết bị hỗ trợ TPM có thể kiểm tra tính toàn vẹn của máy trong quá trình khởi động, cho phép các cơ chế bảo vệ
và phát hiện hoạt động trong phần cứng, trước khi khởi động và trong quá trình khởi động an toàn. Sự đảm bảo về độ tin
cậy và tính toàn vẹn tương tự này có thể được mở rộng ra ngoài hệ điều hành và bộ tải khởi động đến các ứng dụng và
thời gian chạy của vùng chứa. Lưu ý rằng mặc dù các tiêu chuẩn đang được phát triển để cho phép người dùng dịch
vụ đám mây xác minh độ tin cậy phần cứng nhưng không phải tất cả các đám mây đều cung cấp chức năng này cho
khách hàng của họ. Trong trường hợp không cung cấp xác minh kỹ thuật, các tổ chức nên giải quyết các yêu
cầu về độ tin cậy của phần cứng như một phần trong thỏa thuận dịch vụ của họ với các nhà cung cấp đám mây.
Sự phức tạp ngày càng tăng của các hệ thống và bản chất sâu xa của các mối đe dọa ngày nay có nghĩa là bảo mật phải mở
rộng trên tất cả các thành phần công nghệ vùng chứa, bắt đầu từ phần cứng và chương trình cơ sở. Điều này sẽ
tạo thành một mô hình điện toán phân tán đáng tin cậy và cung cấp cách thức đáng tin cậy và an toàn nhất để xây dựng,
chạy, điều phối và quản lý các vùng chứa.
Mô hình điện toán đáng tin cậy phải bắt đầu bằng khả năng khởi động được đo lường/an toàn, cung cấp nền tảng hệ thống
đã được xác minh và xây dựng chuỗi tin cậy bắt nguồn từ phần cứng và mở rộng tới bộ tải khởi động, nhân hệ điều hành
và các thành phần hệ điều hành để cho phép xác minh bằng mật mã các cơ chế khởi động, hình ảnh hệ thống, thời gian chạy
vùng chứa và hình ảnh vùng chứa. Đối với các công nghệ vùng chứa, các kỹ thuật này hiện có thể áp dụng ở các lớp
phần cứng, bộ ảo hóa và hệ điều hành máy chủ, đồng thời đang trong giai đoạn đầu áp dụng các kỹ thuật này cho các
thành phần dành riêng cho vùng chứa.
28
đ
n
b
Ất
p
cm NIST SP 800-190
Vào thời điểm viết bài này, NIST đang cộng tác với các đối tác trong ngành để xây dựng kiến
trúc tham chiếu dựa trên các sản phẩm thương mại sẵn có thể hiện mô hình điện toán đáng tin
cậy cho môi trường container.8
số 8
Để biết thêm thông tin về những nỗ lực trước đây của NIST trong lĩnh vực này, hãy xem NIST IR 7904, Định vị địa lý đáng tin cậy trong đám mây:
Bằng chứng triển khai khái niệm [27].
29
đ
n
b
Ất
p
cm NIST SP 800-190
5 ví dụ về kịch bản mối đe dọa vùng chứa

Để minh họa tính hiệu quả của các biện pháp đối phó được đề xuất từ Phần 4, hãy xem xét các ví dụ về kịch bản mối đe
dọa sau đây đối với vùng chứa.
5.1 Khai thác lỗ hổng trong hình ảnh
Một trong những mối đe dọa phổ biến nhất đối với môi trường được chứa trong container là các lỗ hổng
cấp ứng dụng trong phần mềm trong các container. Ví dụ: một tổ chức có thể xây dựng hình ảnh dựa trên một ứng
dụng web phổ biến. Nếu ứng dụng đó có lỗ hổng, nó có thể được sử dụng để phá hoại ứng dụng trong vùng chứa. Sau khi
bị xâm phạm, kẻ tấn công có thể ánh xạ các hệ thống khác trong môi trường, cố gắng nâng cao đặc quyền trong vùng
chứa bị xâm nhập hoặc lạm dụng vùng chứa để sử dụng trong các cuộc tấn công vào các hệ thống khác (chẳng hạn như
hoạt động như một trình thả tệp hoặc điểm cuối ra lệnh và kiểm soát) .
Các tổ chức áp dụng các biện pháp đối phó được khuyến nghị sẽ có nhiều lớp phòng thủ chuyên sâu chống lại các
mối đe dọa đó:
1. Phát hiện sớm hình ảnh dễ bị tổn thương trong quá trình triển khai và có các biện pháp kiểm soát
nơi ngăn chặn việc triển khai các hình ảnh dễ bị tổn thương sẽ ngăn việc đưa lỗ hổng vào sản xuất.
2. Giám sát và lọc mạng nhận biết vùng chứa sẽ phát hiện các kết nối bất thường
sang các vùng chứa khác trong quá trình cố gắng ánh xạ các hệ thống khác.
3. Giám sát quy trình nhận biết vùng chứa và phát hiện phần mềm độc hại sẽ phát hiện việc chạy các quy trình
độc hại không hợp lệ hoặc không mong muốn cũng như dữ liệu mà chúng đưa vào môi trường.
5.2 Khai thác thời gian chạy container
Mặc dù hiếm khi xảy ra, nhưng nếu thời gian chạy vùng chứa bị xâm phạm, kẻ tấn công có thể sử dụng quyền truy cập
này để tấn công tất cả các vùng chứa trên máy chủ và thậm chí cả chính máy chủ đó.
Các biện pháp giảm nhẹ có liên quan cho kịch bản mối đe dọa này bao gồm:
1. Việc sử dụng các khả năng kiểm soát truy cập bắt buộc có thể tạo ra các rào cản bổ sung để đảm bảo rằng
hoạt động của quy trình và hệ thống tệp vẫn được phân đoạn trong các ranh giới đã xác định.
2. Việc phân chia khối lượng công việc đảm bảo rằng phạm vi xâm phạm sẽ được giới hạn ở các ứng dụng có mức độ
nhạy cảm chung đang chia sẻ máy chủ. Ví dụ: thời gian chạy bị xâm phạm trên máy chủ chỉ chạy ứng dụng web sẽ
không ảnh hưởng đến thời gian chạy trên các máy chủ khác chạy vùng chứa cho ứng dụng tài chính.
3. Các công cụ bảo mật có thể báo cáo về trạng thái dễ bị tổn thương trong thời gian chạy và ngăn chặn
việc triển khai hình ảnh vào các thời gian chạy dễ bị tổn thương có thể ngăn khối lượng công việc chạy ở đó.
5.3 Chạy một hình ảnh bị nhiễm độc
Vì hình ảnh có thể dễ dàng lấy được từ các vị trí công cộng, thường không rõ nguồn gốc, nên kẻ tấn công có thể
nhúng phần mềm độc hại vào trong các hình ảnh được biết là mục tiêu sẽ sử dụng. Vì
30
đ
n
b
Ất
p
Ví dụ: nếu kẻ tấn công xác định rằng mục tiêu đang hoạt động trên diễn đàn thảo luận về một vấn đề cụ thể
dự án và sử dụng hình ảnh do trang web của dự án đó cung cấp, kẻ tấn công có thể tìm cách tạo ra các phiên
bản độc hại của những hình ảnh này để sử dụng trong một cuộc tấn công.
Các biện pháp giảm nhẹ có liên quan bao gồm:
1. Đảm bảo rằng chỉ những hình ảnh đã được hiệu đính, kiểm tra, xác thực và ký điện tử mới được phép tải lên cơ
quan đăng ký của tổ chức.
2. Đảm bảo rằng chỉ những hình ảnh đáng tin cậy mới được phép chạy, điều này sẽ ngăn hình ảnh khỏi
các nguồn bên ngoài, chưa được kiểm tra khỏi việc sử dụng.
3. Tự động quét hình ảnh để tìm lỗ hổng và phần mềm độc hại, có thể phát hiện mã độc như rootkit được
nhúng trong hình ảnh.
4. Triển khai các biện pháp kiểm soát thời gian chạy nhằm hạn chế khả năng lạm dụng tài nguyên, cấp đặc
quyền và chạy các tệp thực thi của vùng chứa.
5. Sử dụng phân đoạn mạng cấp vùng chứa để giới hạn “bán kính vụ nổ” mà hình ảnh bị nhiễm độc có thể gây
ra.
6. Việc xác thực thời gian chạy vùng chứa hoạt động theo đặc quyền tối thiểu và quyền truy cập ít nhất
Nguyên tắc.
7. Xây dựng hồ sơ mối đe dọa về thời gian chạy của vùng chứa. Điều này bao gồm, nhưng không giới hạn,
quy trình, cuộc gọi mạng và thay đổi hệ thống tập tin.
8. Xác thực tính toàn vẹn của hình ảnh trước khi chạy bằng cách tận dụng hàm băm và kỹ thuật số
chữ ký.
9. Hạn chế chạy hình ảnh dựa trên các quy tắc thiết lập lỗ hổng có thể chấp nhận được
mức độ nghiêm trọng. Ví dụ: ngăn không cho chạy các hình ảnh có lỗ hổng có xếp hạng CVSS Trung bình hoặc cao
hơn.
31
đ
n
b
Ất
p
cm NIST SP 800-190
6 cân nhắc về bảo mật vòng đời công nghệ container

Điều cực kỳ quan trọng là phải lập kế hoạch cẩn thận trước khi cài đặt, định cấu hình và triển khai
các công nghệ vùng chứa. Điều này giúp đảm bảo rằng môi trường container an toàn nhất có thể và tuân
thủ tất cả các chính sách có liên quan của tổ chức, quy định bên ngoài và các yêu cầu
khác.
Có rất nhiều điểm tương đồng trong các đề xuất lập kế hoạch và triển khai cho công nghệ container
và giải pháp ảo hóa. Phần 5 của NIST SP 800-125 [1] đã chứa đầy đủ các đề xuất cho các giải pháp ảo
hóa. Thay vì lặp lại tất cả các đề xuất đó ở đây, phần này hướng người đọc đến tài liệu đó và tuyên
bố rằng, ngoài các trường hợp ngoại lệ được liệt kê bên dưới, các tổ chức nên áp dụng tất cả các đề
xuất NIST SP 800-125 Phần 5 trong bối cảnh công nghệ vùng chứa. Ví dụ: thay vì tạo chính
sách bảo mật ảo hóa, hãy tạo chính sách bảo mật công nghệ vùng chứa.
Phần này của tài liệu liệt kê các trường hợp ngoại lệ và bổ sung cho các khuyến nghị Phần 5 của
NIST SP 800-125, được nhóm theo giai đoạn tương ứng trong vòng đời lập kế hoạch và triển khai.
6.1 Giai đoạn khởi đầu
Các tổ chức nên xem xét các chính sách bảo mật khác có thể bị ảnh hưởng như thế nào bởi các vùng
chứa và điều chỉnh các chính sách này nếu cần để xem xét các vùng chứa. Ví dụ: các chính sách ứng
phó sự cố (đặc biệt là điều tra) và quản lý lỗ hổng có thể cần được điều chỉnh để tính đến các yêu
cầu đặc biệt của vùng chứa.
Việc giới thiệu các công nghệ container có thể phá vỡ các phương pháp phát triển phần mềm và
văn hóa hiện có trong tổ chức. Để tận dụng tối đa lợi ích mà bộ chứa có thể mang lại, các quy
trình của tổ chức phải được điều chỉnh để hỗ trợ cách phát triển, chạy và hỗ trợ ứng dụng mới này.
Các phương pháp phát triển truyền thống, kỹ thuật vá lỗi và quy trình nâng cấp hệ thống có thể
không áp dụng trực tiếp vào môi trường được chứa trong container và điều quan trọng là
nhân viên trong tổ chức phải sẵn sàng thích ứng với mô hình mới. Các quy trình mới có thể xem xét và
giải quyết mọi cú sốc văn hóa tiềm ẩn do sự thay đổi công nghệ gây ra. Giáo dục và đào tạo có thể
được cung cấp cho bất kỳ ai tham gia vào vòng đời phát triển phần mềm để cho phép mọi người trở nên
thoải mái với cách mới để xây dựng, vận chuyển và chạy ứng dụng.
6.2 Giai đoạn lập kế hoạch và thiết kế
Việc xem xét cụ thể về vùng chứa chính cho giai đoạn lập kế hoạch và thiết kế là điều tra.
Bởi vì các bộ chứa chủ yếu được xây dựng trên các thành phần đã có trong HĐH nên các công cụ và kỹ
thuật để thực hiện điều tra trong môi trường được chứa trong bộ chứa hầu hết là sự phát triển của
các phương pháp hiện có. Bản chất bất biến của vùng chứa và hình ảnh thực sự có thể cải thiện
khả năng điều tra vì ranh giới giữa những gì hình ảnh nên làm và những gì thực sự xảy ra trong
một sự cố là rõ ràng hơn. Ví dụ: nếu một vùng chứa được khởi chạy để chạy máy chủ web đột nhiên khởi
động chuyển tiếp thư thì rất rõ ràng rằng quy trình mới không phải là một phần của quy trình ban đầu.
32
đ
n
b
Ất
p
cm NIST SP 800-190
và ứng dụng, việc tạo ra sự khác biệt này có thể khó khăn hơn nhiều.
hình ảnh được sử dụng để tạo vùng chứa. Trên nền tảng truyền thống, ít sự tách biệt giữa hệ điều hành hơn
Các tổ chức đã quen thuộc với các hoạt động ứng phó sự cố quy trình, bộ nhớ và ổ đĩa sẽ thấy chúng gần như giống
nhau khi làm việc với các bộ chứa. Tuy nhiên, cũng có một số khác biệt cần ghi nhớ.
Các bộ chứa thường sử dụng hệ thống tệp phân lớp được ảo hóa từ hệ điều hành máy chủ. Việc kiểm tra trực
tiếp các đường dẫn trên máy chủ thường chỉ tiết lộ ranh giới bên ngoài của các lớp này chứ không phải các tệp và
dữ liệu bên trong chúng. Do đó, khi ứng phó với sự cố trong môi trường được chứa trong container, người dùng nên
xác định nhà cung cấp dịch vụ lưu trữ cụ thể đang được sử dụng và hiểu cách kiểm tra ngoại tuyến nội dung
của nhà cung cấp đó một cách chính xác.
Các thùng chứa thường được kết nối với nhau bằng mạng lớp phủ ảo hóa. Các mạng lớp phủ này thường sử dụng
tính năng đóng gói và mã hóa để cho phép lưu lượng được định tuyến qua các mạng hiện có một cách an toàn. Tuy
nhiên, điều này có nghĩa là khi điều tra các sự cố trên mạng container, đặc biệt là khi thực hiện bất kỳ phân
tích gói trực tiếp nào, các công cụ được sử dụng phải nhận biết được các mạng ảo hóa này và hiểu cách trích
xuất các khung IP nhúng từ bên trong chúng để phân tích cú pháp bằng các công cụ hiện có.
Hoạt động của quy trình và bộ nhớ trong các vùng chứa phần lớn tương tự như hoạt động được thấy trong các ứng dụng
truyền thống, nhưng với các quy trình gốc khác nhau. Ví dụ: thời gian chạy của vùng chứa có thể sinh ra tất cả các
quy trình trong vùng chứa theo kiểu lồng nhau, trong đó thời gian chạy là quy trình cấp cao nhất với các quy
trình con cấp một trên mỗi vùng chứa và các quy trình con cấp hai cho mỗi quy trình trong vùng chứa. Ví dụ:
├─containerd─┬───┬───[container1─┬─bash]
│ │ └─8*[{chủ đề}]] │
│ │ ├─container2────┬─start.sh─┬─mongod───22*[{mongod}]
│ │ │ └─node─┬─4*[{V8 WorkerThread}]
│
│ │ │ └─5*[{nút}] │
│ │ └─8*[{chủ đề}] │
│ │ ├─container3────┬─mysqld───28*[{mysqld}]
│ │ └─8*[{chủ đề}] │
6.3 Giai đoạn thực hiện
Sau khi công nghệ container được thiết kế xong, bước tiếp theo là triển khai và thử nghiệm nguyên mẫu thiết
kế trước khi đưa giải pháp vào sản xuất. Xin lưu ý rằng công nghệ vùng chứa không cung cấp các loại khả năng
xem xét nội tâm như công nghệ VM.
NIST SP 800-125 [1] trích dẫn một số khía cạnh của công nghệ ảo hóa cần được đánh giá trước khi triển khai sản xuất,
bao gồm xác thực, kết nối và kết nối mạng, chức năng ứng dụng, quản lý, hiệu suất và tính bảo mật của chính
công nghệ. Ngoài những điều đó, điều quan trọng là phải đánh giá khả năng cách ly của công nghệ container. Đảm bảo
rằng các quy trình trong vùng chứa có thể truy cập tất cả các tài nguyên mà chúng được phép và không thể xem
hoặc truy cập bất kỳ tài nguyên nào khác.
33
đ
n
b
Ất
p
Việc triển khai có thể yêu cầu các công cụ bảo mật mới tập trung đặc biệt vào vùng chứa và ứng dụng gốc
trên nền tảng đám mây, đồng thời có khả năng hiển thị hoạt động của chúng mà các công cụ truyền thống
thiếu. Cuối cùng, việc triển khai cũng có thể bao gồm việc thay đổi cấu hình của các công nghệ và
kiểm soát bảo mật hiện có, chẳng hạn như ghi nhật ký sự kiện bảo mật, quản lý mạng, kho lưu trữ mã
và máy chủ xác thực để hoạt động trực tiếp với các vùng chứa và tích hợp với các công cụ bảo mật
vùng chứa mới này.
Khi quá trình đánh giá nguyên mẫu đã hoàn tất và công nghệ vùng chứa đã sẵn sàng để sử dụng trong sản
xuất, ban đầu nên sử dụng vùng chứa cho một số lượng nhỏ ứng dụng. Các sự cố xảy ra có khả năng ảnh hưởng
đến nhiều ứng dụng, vì vậy, sẽ rất hữu ích nếu bạn sớm xác định những sự cố này để có thể giải quyết trước
khi triển khai thêm. Việc triển khai theo từng giai đoạn cũng cung cấp thời gian cho các nhà phát
triển và nhân viên CNTT (ví dụ: quản trị viên hệ thống, bộ phận trợ giúp) được đào tạo về cách sử dụng
và hỗ trợ.
6.4 Giai đoạn vận hành và bảo trì
Các quy trình vận hành đặc biệt quan trọng để duy trì tính bảo mật của công nghệ vùng chứa và do đó cần
được thực hiện thường xuyên, bao gồm cập nhật tất cả hình ảnh và phân phối những hình ảnh đã
cập nhật đó đến vùng chứa để thay thế các hình ảnh cũ hơn. Các biện pháp bảo mật tốt nhất khác, chẳng hạn
như thực hiện quản lý lỗ hổng và cập nhật cho các lớp hỗ trợ khác như máy chủ và người điều phối, cũng
là những nhiệm vụ vận hành chính đang diễn ra. Tương tự, các công cụ giám sát và bảo mật vùng chứa phải
được tích hợp với các công cụ quản lý sự kiện và thông tin bảo mật (SIEM) hiện có để đảm bảo các sự
kiện liên quan đến vùng chứa diễn ra thông qua cùng các công cụ và quy trình được sử dụng để cung cấp
bảo mật trong toàn bộ phần còn lại của môi trường.
Nếu và khi sự cố bảo mật xảy ra trong môi trường được chứa trong container, các tổ chức nên chuẩn bị ứng
phó bằng các quy trình và công cụ được tối ưu hóa cho các khía cạnh riêng biệt của container.
Hướng dẫn cốt lõi được nêu trong NIST SP 800-61, Hướng dẫn xử lý sự cố bảo mật máy tính [28],
cũng có thể áp dụng rất nhiều cho môi trường được chứa trong container. Tuy nhiên, các tổ chức áp dụng
container phải đảm bảo rằng họ tăng cường phản hồi đối với một số khía cạnh độc đáo của bảo mật
container.
• Vì các ứng dụng trong vùng chứa có thể được điều hành bởi một nhóm khác với nhóm vận hành truyền
thống nên các tổ chức phải đảm bảo rằng bất kỳ đội nào chịu trách nhiệm về hoạt động vùng
chứa đều được đưa vào kế hoạch ứng phó sự cố và hiểu rõ vai trò của họ trong đó.
• Như đã thảo luận trong suốt tài liệu này, tính chất tạm thời và tự động của việc quản lý vùng chứa
có thể không phù hợp với các chính sách và công cụ quản lý tài sản mà tổ chức thường sử
dụng. Các nhóm ứng phó sự cố phải có khả năng biết vai trò, chủ sở hữu và mức độ nhạy cảm của
vùng chứa cũng như có thể tích hợp dữ liệu này vào quy trình của họ.
• Cần xác định rõ các thủ tục để ứng phó với các sự cố liên quan đến container. Vì
Ví dụ: nếu một hình ảnh cụ thể đang bị khai thác nhưng hình ảnh đó lại được sử dụng trên hàng trăm
vùng chứa, thì nhóm phản hồi có thể cần phải tắt tất cả các vùng chứa này để ngăn chặn cuộc tấn
công. Mặc dù các lỗ hổng đơn lẻ từ lâu đã có thể gây ra sự cố trên nhiều hệ thống, nhưng với các
bộ chứa, phản hồi có thể yêu cầu xây dựng lại và triển khai lại hình ảnh mới trên diện rộng,
thay vì cài đặt bản vá cho các hệ thống hiện có. Sự thay đổi này nhằm đáp lại
34
đ
n
b
Ất
p
có thể liên quan đến các nhóm và sự phê duyệt khác nhau và cần được hiểu và thực hành trước.
• Như đã thảo luận trước đây, việc ghi nhật ký và dữ liệu điều tra khác có thể được lưu trữ khác nhau trong một
môi trường đóng container. Các nhóm ứng phó sự cố phải làm quen với các công cụ và kỹ thuật khác
nhau cần thiết để thu thập dữ liệu và có các quy trình được ghi lại cụ thể cho các môi trường
này.
6.5 Giai đoạn xử lý
Khả năng các vùng chứa được triển khai và hủy tự động dựa trên nhu cầu của ứng dụng cho phép các hệ
thống đạt hiệu quả cao nhưng cũng có thể đặt ra một số thách thức đối với các yêu cầu về lưu giữ
hồ sơ, điều tra và dữ liệu sự kiện. Các tổ chức nên đảm bảo có sẵn các cơ chế thích hợp để đáp ứng các
chính sách lưu giữ dữ liệu của họ. Ví dụ về các vấn đề cần được giải quyết là cách hủy vùng chứa và hình
ảnh, dữ liệu nào cần được trích xuất từ vùng chứa trước khi xử lý và cách thực hiện việc trích xuất
dữ liệu đó, cách thu hồi hoặc xóa khóa mật mã được sử dụng bởi vùng chứa, v.v.
Các kho lưu trữ dữ liệu và phương tiện hỗ trợ môi trường được chứa trong container phải được đưa
vào bất kỳ kế hoạch xử lý nào do tổ chức phát triển.
35
đ
n
b
Ất
p
cm NIST SP 800-190
7. Kết luận
Vùng chứa thể hiện sự thay đổi mang tính chuyển đổi trong cách xây dựng và chạy ứng dụng. Họ không
đòi hỏi phải có những biện pháp thực hành tốt nhất về bảo mật mới một cách đáng kể; ngược lại, các khía
cạnh quan trọng nhất của an ninh container là sự cải tiến các kỹ thuật và nguyên tắc đã được thiết lập
tốt. Tài liệu này đã cập nhật và mở rộng các khuyến nghị bảo mật chung để tính đến các rủi ro cụ thể
đối với công nghệ vùng chứa.
Tài liệu này đã thảo luận về một số điểm khác biệt giữa bảo mật vùng chứa và bảo mật các ứng dụng tương
tự trong VM. Sẽ rất hữu ích nếu tóm tắt hướng dẫn trong tài liệu này xung quanh những điểm đó.
Trong môi trường vùng chứa có nhiều thực thể hơn nên các quy trình và công cụ bảo mật phải có khả năng mở
rộng quy mô tương ứng. Quy mô không chỉ có nghĩa là tổng số đối tượng được hỗ trợ trong cơ sở dữ liệu
mà còn có nghĩa là chính sách có thể được quản lý một cách hiệu quả và tự chủ như thế nào.
Nhiều tổ chức phải vật lộn với gánh nặng quản lý bảo mật trên hàng trăm máy ảo. Khi kiến trúc lấy
container làm trung tâm trở thành tiêu chuẩn và các tổ chức này chịu trách nhiệm về hàng nghìn hoặc
hàng chục nghìn container, các biện pháp bảo mật của họ cần nhấn mạnh đến tính tự động hóa và
tính hiệu quả để theo kịp.
Với vùng chứa, tỷ lệ thay đổi sẽ cao hơn nhiều, chuyển từ cập nhật ứng dụng vài lần một năm sang vài lần
một tuần hoặc thậm chí một ngày. Những gì từng được chấp nhận để làm thủ công không còn nữa. Tự động hóa
không chỉ quan trọng trong việc xử lý số lượng thực thể mà còn liên quan đến tần suất các thực thể đó
thay đổi. Khả năng thể hiện chính sách tập trung và có phần mềm quản lý việc thực thi chính sách đó
trên toàn môi trường là rất quan trọng. Các tổ chức sử dụng vùng chứa nên chuẩn bị sẵn sàng để quản lý
tần suất thay đổi này. Điều này có thể đòi hỏi những thực tiễn hoạt động mới về cơ bản và sự phát triển
của tổ chức.
Việc sử dụng vùng chứa chuyển phần lớn trách nhiệm về bảo mật sang cho nhà phát triển, vì vậy
các tổ chức nên đảm bảo nhà phát triển của họ có tất cả thông tin, kỹ năng và công cụ họ cần để đưa ra
quyết định đúng đắn. Ngoài ra, các nhóm bảo mật nên được phép tích cực thực thi chất lượng trong suốt
chu kỳ phát triển. Các tổ chức thành công trong quá trình chuyển đổi này sẽ đạt được lợi ích về bảo
mật nhờ khả năng ứng phó với các lỗ hổng nhanh hơn và ít gánh nặng vận hành hơn bao giờ hết.
Bảo mật phải có tính di động như bản thân các thùng chứa, vì vậy các tổ chức nên áp dụng các kỹ
thuật và công cụ mở và hoạt động trên nhiều nền tảng và môi trường. Nhiều tổ chức sẽ thấy các
nhà phát triển xây dựng trong một môi trường, thử nghiệm trong môi trường khác và triển khai trong môi
trường thứ ba, vì vậy, điều quan trọng là phải có sự nhất quán trong đánh giá và thực thi trên các môi
trường này. Tính di động không chỉ liên quan đến môi trường mà còn liên quan đến thời gian. Các biện pháp
triển khai và tích hợp liên tục làm xói mòn các bức tường truyền thống giữa các giai đoạn của chu kỳ
phát triển và triển khai, vì vậy các tổ chức cần đảm bảo các biện pháp bảo mật tự động, nhất quán trong
quá trình tạo hình ảnh, lưu trữ hình ảnh trong sổ đăng ký và chạy hình ảnh trong vùng chứa.
Các tổ chức điều hướng những thay đổi này có thể bắt đầu tận dụng các vùng chứa để thực sự cải thiện tính
bảo mật tổng thể của mình. Tính chất bất biến và khai báo của vùng chứa cho phép các tổ chức
bắt đầu hiện thực hóa tầm nhìn về bảo mật tập trung vào ứng dụng, tự động hơn, đòi hỏi
36
đ
n
b
Ất
p
sự tham gia thủ công tối thiểu và tự cập nhật khi ứng dụng thay đổi. Bộ chứa là một khả năng hỗ
trợ trong các tổ chức đang chuyển từ các mô hình bảo mật phản ứng, thủ công, chi phí cao sang các mô
hình cho phép mở rộng quy mô và hiệu quả tốt hơn, do đó giảm thiểu rủi ro.
37
đ
n
b
Ất
p
cm NIST SP 800-190
Phụ lục A—Tài nguyên của NIST để bảo mật các thành phần không cốt lõi
Phụ lục này liệt kê các tài nguyên NIST để bảo mật các thành phần công nghệ vùng chứa không cốt lõi, bao
gồm hệ thống dành cho nhà phát triển, hệ thống kiểm tra và công nhận, hệ thống quản trị viên cũng như phần
cứng máy chủ và trình quản lý máy ảo. Nhiều nguồn lực hơn có sẵn từ các tổ chức khác.
Bảng 1: Tài nguyên NIST để bảo mật các thành phần không cốt lõi
Tên tài nguyên và URI Khả năng ứng dụng
SP 800-40 Bản sửa đổi 3, Hướng dẫn về Công nghệ Quản lý Bản vá dành cho Doanh nghiệp https:// Tất cả các sản phẩm và hệ thống CNTT
doi.org/10.6028/NIST.SP.800-40r3
SP 800-46 Bản sửa đổi 2, Hướng dẫn về Làm việc từ xa cho doanh nghiệp, Truy cập từ xa và Bảo mật Hệ điều hành máy khách, ứng
khi mang theo thiết bị của riêng bạn (BYOD) dụng máy khách
https://doi.org/10.6028/NIST.SP.800-46r2
SP 800-53 Bản sửa đổi 4, Kiểm soát bảo mật và quyền riêng tư cho các tổ chức và hệ thống Tất cả các sản phẩm và hệ thống CNTT
thông tin liên bang
SP 800-70 Bản sửa đổi 3, Chương trình danh sách kiểm tra quốc gia dành cho sản phẩm CNTT: Hướng dẫn dành cho Hệ điều hành máy chủ, hệ điều
người dùng và nhà phát triển danh sách kiểm tra hành máy khách, ứng dụng máy
https://doi.org/10.6028/NIST.SP.800-70r3 chủ, ứng dụng máy khách
SP 800-83 Bản sửa đổi 1, Hướng dẫn Phòng ngừa và Xử lý Sự cố Phần mềm độc hại cho Máy tính để Hệ điều hành máy khách, ứng
bàn và Máy tính xách tay dụng máy khách
SP 800-123, Hướng dẫn bảo mật máy chủ chung https:// May chu
doi.org/10.6028/NIST.SP.800-123
SP 800-124 Bản sửa đổi 1, Hướng dẫn Quản lý Bảo mật Thiết bị Di động trong Doanh nghiệp Thiêt bi di đô ng
SP 800-125, Hướng dẫn bảo mật cho công nghệ ảo hóa hoàn toàn https://doi.org/ Hypervisor và máy ảo
10.6028/NIST.SP.800-125
SP 800-125A, Khuyến nghị bảo mật cho việc triển khai Hypervisor (Dự thảo thứ hai) https:// Hypervisor và máy ảo
csrc.nist.gov/publications/detail/sp/800-125A/draft
SP 800-125B, Cấu hình mạng ảo an toàn cho máy ảo (VM) Hypervisor và máy ảo
Sự bảo vệ
https://doi.org/10.6028/NIST.SP.800-125B
SP 800-147, Nguyên tắc bảo vệ BIOS Phần cứng máy khách
https://doi.org/10.6028/NIST.SP.800-147
SP 800-155, Nguyên tắc đo lường tính toàn vẹn của BIOS Phần cứng máy khách
https://csrc.nist.gov/publications/detail/sp/800-155/draft
SP 800-164, Nguyên tắc về bảo mật bắt nguồn từ phần cứng trong thiết bị di động Thiêt bi di đô ng
https://csrc.nist.gov/publications/detail/sp/800-164/draft
38
đ
n
b
Ất
p
cm NIST SP 800-190
Phụ lục B—NIST SP 800-53 và Kiểm soát bảo mật khung an ninh mạng NIST
Liên quan đến công nghệ container
Các biện pháp kiểm soát bảo mật từ NIST SP 800-53 Phiên bản 4 [29] quan trọng nhất đối với công nghệ
vùng chứa được liệt kê trong Bảng 2.
Bảng 2: Kiểm soát bảo mật từ NIST SP 800-53 đối với bảo mật công nghệ vùng chứa
Kiểm soát NIST SP 800-53 Kiểm soát liên quan Người giới thiệu
AC-2, Tài khoản AC-3, AC-4, AC-5, AC-6, AC-10, AC-17, AC-19, AC-20,
Sự quản lý AU-9, IA-2, IA-4, IA-5, IA-8, CM-5, CM-6, CM-11, MA-3,
MA-4, MA-5, PL-4, SC-13
AC-3, Thực thi quyền truy cập AC-2, AC-4, AC-5, AC-6, AC-16, AC-17, AC-18, AC-19,
AC-20, AC-21, AC-22, AU-9, CM-5, CM-6, CM-11, MA-3,
MA-4, MA-5, PE-3
AC-4, Luồng thông tin AC-3, AC-17, AC-19, AC-21, CM-6, CM-7, SA-8, SC-2,
Thực thi SC-5, SC-7, SC-18
AC-6, Đặc quyền tối thiểu AC-2, AC-3, AC-5, CM-6, CM-7, PL-2
AC-17, Truy cập từ xa AC-2, AC-3, AC-18, AC-19, AC-20, CA-3, CA-7, CM-8, NIST SP 800-46, 800-77,
IA-2, IA-3, IA-8, MA-4, PE-17, PL-4, SC-10, SI-4 800-113, 800-114, 800-
121
AT-3, Bảo mật dựa trên vai trò AT-2, AT-4, PL-4, PS-7, SA-3, SA-12, SA-16 CFR Phần 5 Tiểu phần C
Đào tạo (5C.FR930.301); NIST
SP 800-16, 800- 50
AU-2, Sự kiện kiểm toán AC-6, AC-17, AU-3, AU-12, MA-4, MP-2, MP-4, SI-4 NIST SP 800-92;
https://idmanagement.gov/
AU-5, Phản hồi kiểm tra AU-4, SI-12

Lỗi xử lý
AU-6, Đánh giá kiểm toán, AC-2, AC-3, AC-6, AC-17, AT-3, AU-7, AU-16, CA-7, CM-
Phân tích và báo cáo 5, CM-10, CM-11, IA-3, IA-5, IR-5, IR-6, MA-4, MP-4, PE-
3, PE-6, PE-14, PE-16, RA-5, SC-7, SC-18, SC-19, SI-3,
SI-4, SI-7
AU-8, Dấu thời gian AU-3, AU-12
AU-9, Bảo vệ kiểm toán AC-3, AC-6, MP-2, MP-4, PE-2, PE-3, PE-6
Thông tin
AU-12, Thế hệ kiểm toán AC-3, AU-2, AU-3, AU-6, AU-7
CA-9, Hệ thống nội bộ AC-3, AC-4, AC-18, AC-19, AU-2, AU-12, CA-7, CM-2,
Kết nối IA-3, SC-7, SI-4
CM-2, Đường cơ sở CM-3, CM-6, CM-8, CM-9, SA-10, PM-5, PM-7 NIST SP 800-128
Cấu hình
CM-3, Cấu hình CA-7, CM-2, CM-4, CM-5, CM-6, CM-9, SA-10, SI-2, SI-12 NIST SP 800-128
Kiểm soát thay đổi
CM-4, Tác động an ninh CA-2, CA-7, CM-3, CM-9, SA-4, SA-5, SA-10, SI-2 NIST SP 800-128
Phân tích
CM-5, Hạn chế truy cập để AC-3, AC-6, PE-3

thay đổi
CM-6, Cấu hình AC-19, CM-2, CM-3, CM-7, SI-4 Bản ghi nhớ OMB 07-11, 07-18,
Cài đặt 08-22; NIST SP 800-70,
800-128; https://
nvd.nist.gov; https://
checklists.nist.gov; https://
www.nsa.gov
39
đ
n
b
Ất
p
cm NIST SP 800-190
Kiểm soát NIST SP 800-53
CM-9, Cấu hình

Kế hoạch quản lý
CP-2, Kế hoạch dự phòng

Kiểm soát liên quan
CM-7, Chức năng tối thiểu AC-6, CM-2, RA-5, SA-5, SC-7
CM-2, CM-3, CM-4, CM-5, CM-8, SA-10

AC-14, CP-6, CP-7, CP-8, CP-9, CP-10, IR-4, IR-8, MP-

Người giới thiệu
Hướng dẫn DoD 8551.01
NIST SP 800-128
Liên tục liên bang

2, MP-4, MP-5, PM-8, PM-11 Chỉ thị 1; NIST SP 800-
34
CP-9, Hệ thống thông tin CP-2, CP-6, MP-4, MP-5, SC-13 NIST SP 800-34
Hỗ trợ
CP-10, Hệ thống thông tin CA-2, CA-6, CA-7, CP-2, CP-6, CP-7, CP-9, SC-24 Liên tục liên bang
Phục hồi và Chỉ thị 1; NIST SP 800-
hoàn nguyên 34
IA-2, Nhận dạng và AC-2, AC-3, AC-14, AC-17, AC-18, IA-4, IA-5, IA-8 HSPD-12; OMB
Xác thực Bản ghi nhớ 04-04, 06-16,
(Người dùng tổ chức) 11-11; FIPS 201; NIST
SP 800-63, 800-73, 800-
76, 800-78; Lộ
trình FICAM
và Hướng dẫn Thực hiện;
IA-4, Mã định danh AC-2, IA-2, IA-3, IA-5, IA-8, SC-37 FIPS 201; NIST SP 800-
Sự quản lý 73, 800-76, 800-78
IA-5, Trình xác thực AC-2, AC-3, AC-6, CM-6, IA-2, IA-4, IA-8, PL-4, PS-5, Bản ghi nhớ OMB 04-04,
Sự quản lý PS-6, SC-12, SC-13, SC-17, SC-28 11-11; FIPS 201; NIST
SP 800-63, 800-73, 800-
76, 800-78; Lộ trình
FICAM và Hướng
dẫn Thực hiện; https://
idmanagement.gov/
IR-1, Ứng phó sự cố PM-9 NIST SP 800-12, 800-61,

Chính sách và thủ tục 800-83, 800-100
IR-4, Xử lý sự cố AU-6, CM-6, CP-2, CP-4, IR-2, IR-3, IR-8, PE-6, SC-5, EO 13587; NIST SP 800-
SC-7, SI-3, SI-4, SI-7 61
MA-2, có kiểm soát CM-3, CM-4, MA-4, MP-6, PE-16, SA-12, SI-2
BẢO TRÌ
MA-4, Không cục bộ AC-2, AC-3, AC-6, AC-17, AU-2, AU-3, IA-2, IA-4, IA-5, FIPS 140-2, 197, 201;
BẢO TRÌ IA-8, MA-2, MA-5, MP-6, PL-2, SC-7, SC-10, SC-17 NIST SP 800-63, 800-88;
Chính sách CNSS 15
PL-2, Bảo mật hệ thống AC-2, AC-6, AC-14, AC-17, AC-20, CA-2, CA-3, CA-7, NIST SP 800-18
Kế hoạch CM-9, CP-2, IR-8, MA-4, MA-5, MP-2, MP-4, MP-5, PL-7,
PM-1, PM-7, PM-8, PM-9, PM-11, SA-5, SA-17
PL-4, Quy tắc ứng xử AC-2, AC-6, AC-8, AC-9, AC-17, AC-18, AC-19, AC-20, NIST SP 800-18
AT-2, AT-3, CM-11, IA-2, IA-4, IA-5, MP-7, PS-6, PS-8,
SA-5
RA-2, Bảo mật CM-8, MP-4, RA-3, SC-7 FIPS 199; NIST SP 800-
Phân loại 30, 800-39, 800-60
RA-3, Đánh giá rủi ro RA-2, PM-9 Biên bản ghi nhớ OMB 04-
04; NIST SP 800-30,
800-39;
SA-10, Nhà phát triển CM-3, CM-4, CM-9, SA-12, SI-2 NIST SP 800-128
Cấu hình
Sự quản lý
40
đ
n
b
Ất
p
cm NIST SP 800-190
Kiểm soát NIST SP 800-53
SA-11, Bảo mật dành cho nhà phát triển
Kiểm tra và đánh giá

Kiểm soát liên quan
CA-2, CM-4, SA-3, SA-4, SA-5, SI-2

800-53A;
Người giới thiệu
ISO/IEC 15408; NIST SP
https://nvd.nist.gov;
http://cwe.mitre.org;
http://cve.mitre.org;
http://capec.mitre.org
SA-15, Phát triển SA-3, SA-8

Quy trình, tiêu chuẩn và
Công cụ
SA-19, Thành phần PE-3, SA-12, SI-7

Tính xác thực
SC-2, Ứng dụng SA-4, SA-8, SC-3

Phân vùng
SC-4, Thông tin trong AC-3, AC-4, MP-6

Tài nguyên được chia sẻ
SC-6, Tài nguyên

khả dụng
SC-8, truyền tải AC-17, PE-4 FIPS 140-2, 197; NIST

Tính bảo mật và SP 800-52, 800-77, 800-
Chính trực 81, 800-113; Chính sách CNSS
15; NSTISSI số 7003
SI-2, Khắc phục lỗ hổng CA-2, CA-7, CM-3, CM-5, CM-8, MA-2, IR-4, RA-5, SA- NIST SP 800-40, 800-
10, SA-11, SI-11 128
SI-4, Hệ thống thông tin AC-3, AC-4, AC-8, AC-17, AU-2, AU-6, AU-7, AU-9, AU- NIST SP 800-61, 800-83,
Giám sát 12, CA-7, IR-4, PE-3, RA-5, SC-7, SC-26, SC-35, SI-3, 800-92, 800-137
SI-7
SI-7, Tính toàn vẹn của phần SA-12, SC-8, SC-13, SI-3 NIST SP 800-147, 800-
mềm, phần sụn và thông tin 155
Danh sách bên dưới trình bày chi tiết các danh mục phụ của Khung bảo mật không gian mạng NIST [30] quan
trọng nhất đối với bảo mật công nghệ vùng chứa.
• Xác định: Quản lý tài sản
o ID.AM-3: Luồng dữ liệu và truyền thông của tổ chức được ánh xạ
o ID.AM-5: Các tài nguyên (ví dụ: phần cứng, thiết bị, dữ liệu và phần mềm) được ưu tiên dựa trên
phân loại, mức độ quan trọng và giá trị kinh doanh của chúng
• Xác định: Đánh giá rủi ro

o ID.RA-1: Các lỗ hổng tài sản được xác định và ghi lại
o ID.RA-3: Các mối đe dọa, cả bên trong và bên ngoài, được xác định và ghi lại
o ID.RA-4: Các tác động và khả năng có thể xảy ra đối với hoạt động kinh doanh được xác định
o ID.RA-5: Các mối đe dọa, lỗ hổng, khả năng và tác động được sử dụng để xác định rủi ro
o ID.RA-6: Phản hồi rủi ro được xác định và ưu tiên

• Bảo vệ: Kiểm soát truy cập
o PR.AC-1: Danh tính và thông tin xác thực được quản lý cho các thiết bị và người dùng được ủy quyền
o PR.AC-2: Quyền truy cập vật lý vào tài sản được quản lý và bảo vệ
o PR.AC-3: Quản lý quyền truy cập từ xa
o PR.AC-4: Quyền truy cập được quản lý, kết hợp các nguyên tắc về đặc quyền tối thiểu và phân chia
nhiệm vụ
41
đ
n
b
Ất
p
cm NIST SP 800-190
• Bảo vệ: Nhận thức và Đào tạo

o PR.AT-2: Người dùng đặc quyền hiểu rõ vai trò và trách nhiệm
o PR.AT-5: Nhân viên an ninh vật lý và thông tin hiểu rõ vai trò và trách nhiệm
• Bảo vệ: Bảo mật dữ liệu

o PR.DS-2: Dữ liệu đang truyền được bảo vệ
o PR.DS-4: Năng lực phù hợp để đảm bảo duy trì tính sẵn sàng
o PR.DS-5: Triển khai các biện pháp bảo vệ chống rò rỉ dữ liệu
o PR.DS-6: Cơ chế kiểm tra tính toàn vẹn được sử dụng để xác minh phần mềm, chương trình cơ sở và
tính toàn vẹn thông tin
• Bảo vệ: Quy trình và thủ tục bảo vệ thông tin
o PR.IP-1: Cấu hình cơ bản của hệ thống công nghệ thông tin/điều khiển công nghiệp được
tạo và duy trì
o PR.IP-3: Có sẵn các quy trình kiểm soát thay đổi cấu hình
o PR.IP-6: Dữ liệu bị hủy theo chính sách
o PR.IP-9: Các kế hoạch ứng phó (Ứng phó sự cố và Tiếp tục kinh doanh) và kế hoạch khắc phục
(Khôi phục sự cố và Phục hồi thảm họa) được áp dụng và quản lý
o PR.IP-12: Kế hoạch quản lý lỗ hổng được phát triển và triển khai
• Bảo vệ: Bảo trì
o PR.MA-1: Việc bảo trì và sửa chữa tài sản của tổ chức được thực hiện và ghi lại kịp thời bằng
các công cụ được phê duyệt và kiểm soát
o PR.MA-2: Việc bảo trì từ xa tài sản của tổ chức được phê duyệt, ghi nhật ký và
được thực hiện theo cách ngăn chặn truy cập trái phép
• Bảo vệ: Công nghệ bảo vệ

o PR.PT-1: Hồ sơ kiểm tra/nhật ký được xác định, ghi lại, thực hiện và xem xét theo chính sách
o PR.PT-3: Quyền truy cập vào hệ thống và tài sản được kiểm soát, kết hợp nguyên tắc ít chức
năng nhất
• Phát hiện: Sự bất thường và Sự kiện
o DE.AE-2: Các sự kiện được phát hiện sẽ được phân tích để hiểu mục tiêu và phương thức tấn công
• Phát hiện: Giám sát liên tục bảo mật

o DE.CM-1: Mạng được giám sát để phát hiện các sự kiện an ninh mạng tiềm ẩn
o DE.CM-7: Giám sát nhân sự, kết nối, thiết bị và phần mềm trái phép
được thực hiện
• Trả lời: Lập kế hoạch ứng phó

o RS.RP-1: Kế hoạch ứng phó được thực hiện trong hoặc sau sự kiện
• Trả lời: Phân tích

o RS.AN-1: Thông báo từ hệ thống phát hiện được điều tra
o RS.AN-3: Thực hiện pháp y
• Ứng phó: Giảm nhẹ

o RS.MI-1: Sự cố được ngăn chặn
o RS.MI-2: Giảm thiểu sự cố

o RS.MI-3: Các lỗ hổng mới được xác định được giảm nhẹ hoặc được ghi lại là đã được chấp nhận
rủi ro
42
đ
n
b
Ất
p
cm NIST SP 800-190
• Phục hồi: Lập kế hoạch phục hồi

o RC.RP-1: Kế hoạch khôi phục được thực hiện trong hoặc sau sự kiện
Bảng 3 liệt kê các biện pháp kiểm soát bảo mật từ NIST SP 800-53 Phiên bản 4 [29] có
thể được thực hiện một phần hoặc hoàn toàn bằng cách sử dụng công nghệ vùng chứa. Cột ngoài cùng
bên phải liệt kê các phần của tài liệu này ánh xạ tới từng điều khiển NIST SP 800-53.
Bảng 3: Các biện pháp kiểm soát NIST SP 800-53 được hỗ trợ bởi Công nghệ vùng chứa
NIST SP 800-53 Mức độ liên quan của công nghệ container Phần liên quan của
Điều khiển Tài liệu này
CM-3, Cấu hình Hình ảnh có thể được sử dụng để giúp quản lý kiểm soát thay đổi cho ứng dụng. 2.1, 2.2, 2.3, 2.4, 4.1
Kiểm soát thay đổi
SC-2, Ứng dụng Việc tách chức năng của người dùng khỏi chức năng của quản trị viên có thể 2 (giới thiệu), 2.3,
Phân vùng được thực hiện một phần bằng cách sử dụng các bộ chứa hoặc các công nghệ ảo hóa 4.5.2
khác để chức năng này được thực hiện trong các bộ chứa khác nhau.
SC-3, Bảo mật Việc tách các chức năng bảo mật khỏi các chức năng không bảo mật có thể được 2 (giới thiệu), 2.3,
Cách ly chức năng thực hiện một phần bằng cách sử dụng các bộ chứa hoặc các công nghệ ảo hóa 4.5.2
khác để các chức năng này được thực hiện trong các bộ chứa khác nhau.
SC-4, Thông tin trong Công nghệ vùng chứa được thiết kế để hạn chế quyền truy cập của mỗi vùng chứa 2 (giới thiệu), 2.2,
Tài nguyên được chia sẻ vào các tài nguyên được chia sẻ để thông tin không thể 2.3, 4.4
vô tình bị rò rỉ từ thùng này sang thùng khác.
SC-6, Tài nguyên Các tài nguyên tối đa có sẵn cho mỗi vùng chứa có thể được chỉ định, do 2.2, 2.3
khả dụng đó bảo vệ tính khả dụng của tài nguyên bằng cách không cho phép bất kỳ
vùng chứa nào tiêu thụ quá nhiều tài nguyên.
SC-7, Ranh giới Ranh giới có thể được thiết lập và thực thi giữa các container để hạn chế sự liên 2 (giới thiệu), 2.2,
Sự bảo vệ lạc của chúng với nhau. 2.3, 4.4
SC-39, Quy trình Nhiều vùng chứa có thể chạy các tiến trình đồng thời trên cùng một máy 2 (giới thiệu), 2.1,
Sự cách ly chủ, nhưng các tiến trình đó được tách biệt với nhau. 2.2, 2.3, 4.4
SI-7, Phần mềm, Những thay đổi trái phép đối với nội dung của hình ảnh có thể dễ dàng bị 2.3, 4.1, 4.2
Phần sụn và phát hiện và hình ảnh đã thay đổi được thay thế bằng một bản sao tốt đã biết.
Tính toàn vẹn thông tin
SI-14, Không Hình ảnh chạy trong vùng chứa được thay thế khi cần bằng các phiên bản hình 2.1, 2.3, 4.1
Kiên trì ảnh mới, do đó dữ liệu, tệp, tệp thực thi và thông tin khác được lưu
trữ trong hình ảnh đang chạy không tồn tại lâu dài.
Tương tự như Bảng 3, Bảng 4 liệt kê các danh mục phụ Khung an ninh mạng NIST [30] có thể được thực
hiện một phần hoặc toàn bộ bằng cách sử dụng các công nghệ vùng chứa. Cột ngoài cùng bên phải liệt
kê các phần của tài liệu này ánh xạ tới từng danh mục con Khung An ninh mạng.
Bảng 4: Các danh mục phụ của Khung an ninh mạng NIST được hỗ trợ bởi Công nghệ container
Tiểu thể loại khung an ninh mạng Mức độ liên quan của công nghệ container Các phần liên quan của
tài liệu này
PR.DS-4: Năng lực phù hợp để đảm bảo duy trì Các tài nguyên tối đa có sẵn cho mỗi vùng chứa có 2.2, 2.3
tính sẵn sàng thể được chỉ định, do đó bảo vệ tính khả dụng của tài
nguyên bằng cách không cho phép bất kỳ vùng chứa nào
tiêu thụ quá nhiều tài nguyên.
43
đ
n
b
Ất
p
cm NIST SP 800-190
Khung an ninh mạng

Tiểu thể loại
PR.DS-5: Triển khai các biện pháp bảo vệ

chống rò rỉ dữ liệu
Mức độ liên quan của công nghệ container
Công nghệ vùng chứa được thiết kế để hạn chế quyền truy cập
của mỗi vùng chứa vào các tài nguyên được chia sẻ để
thông tin đó không thể vô tình bị rò rỉ từ vùng chứa này

sang vùng chứa khác.
Các phần liên quan của
tài liệu này
2 (giới thiệu), 2.2, 2.3,

4.4
PR.DS-6: Cơ chế kiểm tra tính toàn Những thay đổi trái phép đối với nội dung của hình ảnh có thể 2.3, 4.1, 4.2
vẹn được sử dụng để xác minh tính toàn dễ dàng bị phát hiện và hình ảnh đã thay đổi được thay
vẹn của phần mềm, chương trình cơ sở và thế bằng một bản sao tốt đã biết.
thông tin
PR.DS-7: (Các) môi trường phát triển và thử nghiệm Việc sử dụng vùng chứa giúp dễ dàng có các môi 2.1, 2.3
tách biệt với môi trường sản xuất trường phát triển, thử nghiệm và sản xuất riêng biệt vì có
thể sử dụng cùng một hình ảnh trong tất cả các môi trường
mà không cần điều chỉnh.
PR.IP-3: Có sẵn các quy trình kiểm soát thay Hình ảnh có thể được sử dụng để giúp quản lý kiểm soát 2.1, 2.2, 2.3, 2.4, 4.1
đổi cấu hình thay đổi cho ứng dụng.
Thông tin về các biện pháp kiểm soát và hướng dẫn triển khai có thể có này có thể được tìm thấy
trong các ấn phẩm sau của NIST:
• FIPS 140-2, Yêu cầu bảo mật cho mô-đun mật mã
• FIPS 197, Tiêu chuẩn mã hóa nâng cao (AES)
• FIPS 199, Tiêu chuẩn bảo mật phân loại thông tin và thông tin liên bang
Hệ thống
• FIPS 201-2, Xác minh danh tính cá nhân (PIV) của nhân viên và nhà thầu liên bang
• SP 800-12 Rev. 1, Giới thiệu về Bảo mật Thông tin
• Dự thảo SP 800-16 Bản sửa đổi 1, Mô hình dựa trên vai trò đối với thông tin liên bang
Đào tạo Công nghệ/An ninh mạng
• SP 800-18 Bản sửa đổi 1, Hướng dẫn Phát triển Kế hoạch Bảo mật cho Hệ thống Thông tin Liên bang
• SP 800-30 Bản sửa đổi 1, Hướng dẫn Tiến hành Đánh giá Rủi ro
• SP 800-34 Bản sửa đổi 1, Hướng dẫn Lập kế hoạch Dự phòng cho Hệ thống Thông tin Liên bang
• SP 800-39, Quản lý rủi ro bảo mật thông tin: Tổ chức, sứ mệnh và thông tin
Chế độ xem hệ thống
• SP 800-40 Phiên bản 3, Hướng dẫn về Công nghệ Quản lý Bản vá Doanh nghiệp
• SP 800-46 Phiên bản 2, Hướng dẫn về làm việc từ xa cho doanh nghiệp, truy cập từ xa và bảo mật khi mang theo thiết
bị của riêng bạn (BYOD)
• SP 800-50, Xây dựng nhận thức và đào tạo về bảo mật công nghệ thông tin
Chương trình
• SP 800-52 Bản sửa đổi 1, Nguyên tắc lựa chọn, cấu hình và sử dụng triển khai bảo mật lớp vận
chuyển (TLS)
44
đ
n
b
Ất
p
cm NIST SP 800-190
Tổ chức
• SP 800-53 Bản sửa đổi 4, Kiểm soát An ninh và Quyền riêng tư cho Hệ thống Thông tin Liên bang và
• SP 800-53A Rev. 4, Đánh giá các biện pháp kiểm soát bảo mật và quyền riêng tư trong thông tin liên bang
Hệ thống và Tổ chức: Xây dựng kế hoạch đánh giá hiệu quả
• SP 800-60 Rev. 1 Tập. 1, Hướng dẫn lập bản đồ các loại thông tin và thông tin
Hệ thống đến danh mục bảo mật

• SP 800-61 Phiên bản 2, Hướng dẫn Xử lý Sự cố Bảo mật Máy tính
• SP 800-63 Phiên bản 3, Nguyên tắc nhận dạng kỹ thuật số
• SP 800-70 Rev. 3, Chương trình danh sách kiểm tra quốc gia dành cho sản phẩm CNTT: Hướng dẫn về danh sách kiểm tra
Người dùng và Nhà phát triển
• SP 800-73-4, Giao diện xác minh danh tính cá nhân
• SP 800-76-2, Thông số sinh trắc học để xác minh danh tính cá nhân
• SP 800-77, Hướng dẫn về IPsec VPN
• SP 800-78-4, Thuật toán mật mã và kích thước khóa để nhận dạng cá nhân
Xác minh (PIV)
• SP 800-81-2, Hướng dẫn triển khai hệ thống tên miền an toàn (DNS)
• SP 800-83 Phiên bản 1, Hướng dẫn ngăn chặn và xử lý sự cố phần mềm độc hại dành cho máy tính để bàn và
Máy tính xách tay
• SP 800-88 Bản sửa đổi 1, Hướng dẫn Vệ sinh Phương tiện Truyền thông
• SP 800-92, Hướng dẫn quản lý nhật ký bảo mật máy tính
• SP 800-100, Cẩm nang bảo mật thông tin: Hướng dẫn dành cho người quản lý
• SP 800-113, Hướng dẫn về SSL VPN
• SP 800-114 Rev. 1, Hướng dẫn sử dụng về làm việc từ xa và mang theo thiết bị của riêng bạn (BYOD)
Bảo vệ
• SP 800-121 Phiên bản 2, Hướng dẫn Bảo mật Bluetooth
• SP 800-128, Hướng dẫn quản lý thông tin tập trung vào bảo mật
Hệ thống
• SP 800-137, Giám sát liên tục an ninh thông tin (ISCM) dành cho liên bang
Hệ thống thông tin và tổ chức
• SP 800-147, Nguyên tắc bảo vệ BIOS
• Dự thảo SP 800-155, Nguyên tắc đo lường tính toàn vẹn của BIOS
45
đ
n
b
Ất
p
cm NIST SP 800-190
Phụ lục C—Từ viết tắt

Các từ viết tắt được chọn và các từ viết tắt được sử dụng trong bài viết này được định nghĩa dưới đây.
AES Chuẩn Mã hóa Cấp cao
API Giao diện lập trình ứng dụng
AUFS Hệ thống tập tin hợp nhất nhiều lớp nâng cao
BIOS Hệ thống đầu vào/đầu ra cơ bản
BYOD Mang thiết bị của riêng bạn
nhóm Nhóm kiểm soát
CIS Trung tâm An ninh Internet
CMVP Chương trình xác thực mô-đun mật mã
CVE Các lỗ hổng và nguy cơ phơi nhiễm phổ biến
CVSS Hệ thống chấm điểm lỗ hổng bảo mật phổ biến
DevOps Phát triển và vận hành
DNS Hệ Thống Tên Miền
FIPS Tiêu chuẩn xử lý thông tin liên bang
ĐẦU TIÊN Diễn đàn dành cho Đội ngũ An ninh và Ứng phó Sự cố
FISMA Đạo luật hiện đại hóa an ninh thông tin liên bang
BÓNG ĐÁ Hành động tự do thông tin
GB Gigabyte
Vào/ra
Đầu ra đầu vào
IP giao thức Internet
IPS Hệ thống ngăn chặn xâm nhập
NÓ công nghệ thông tin
ITL Phòng thí nghiệm công nghệ thông tin
LXC Vùng chứa Linux
MAC Kiểm soát truy cập bắt buộc
NIST Viện Tiêu chuẩn và Công nghệ
NTFS Hệ thống tập tin NT
OMB Văn phòng Quản lý và Ngân sách
hệ điều hành
Hệ điều hành
PIV Xác minh danh tính cá nhân
46
đ
nt
p
cm NIST SP 800-190
RTM
SDN
seccomp
Nguồn gốc của niềm tin để đo lường
Mạng được xác định bằng phần mềm
Máy tính an toàn

SIEM
b
Quản lý sự kiện và thông tin bảo mật
Ấ
SP Ấn phẩm đặc biệt
SQL Structured Query Language

SSH Vỏ an toàn
SSL Lớp cổng bảo mật
TLS Bảo mật tầng vận tải
TPM Mô-đun nền tảng đáng tin cậy
URI Mã định danh tài nguyên thống nhất
CHÚNG TA Hoa Kỳ
USCIS Dịch vụ Di trú và Nhập tịch Hoa Kỳ
máy ảo Máy ảo
VPN Mạng riêng ảo
WAF Tường lửa ứng dụng web
47
n
b
Ất
p
cm
đ NIST SP 800-190
Phụ lục D—Bảng thuật ngữ
Ảo hóa ứng
dụng
Một dạng ảo hóa hiển thị một nhân hệ điều hành dùng chung duy nhất cho nhiều
phiên bản ứng dụng riêng biệt, mỗi phiên bản này được giữ cách ly với tất cả
các phiên bản khác trên máy chủ.
Lớp nền Lớp bên dưới của hình ảnh mà trên đó tất cả các thành phần khác được thêm vào.
Thùng đựng hàng Một phương pháp đóng gói và chạy ứng dụng một cách an toàn trong môi trường ảo
hóa ứng dụng. Còn được gọi là vùng chứa ứng dụng hoặc vùng chứa ứng dụng máy
chủ.
Thời gian chạy của vùng chứa Môi trường cho từng vùng chứa; bao gồm các nhị phân phối hợp
nhiều thành phần hệ điều hành giúp tách biệt tài nguyên và cách sử dụng tài nguyên
để chạy các container.
Hệ điều hành dành Một hệ điều hành máy chủ tối giản được thiết kế rõ ràng để chỉ chạy các
riêng cho vùng chứa container.
Ảo hóa hệ Một dạng ảo hóa cho phép nhiều vùng chứa chia sẻ cùng một bộ lưu trữ vật lý mà
thống tập tin không có khả năng truy cập hoặc thay đổi bộ lưu trữ của các vùng chứa khác.
Hệ điều hành đa Một hệ điều hành máy chủ có thể được sử dụng để chạy nhiều loại ứng
năng dụng, không chỉ các ứng dụng trong vùng chứa.
Hệ điều hành máy Nhân hệ điều hành được chia sẻ bởi nhiều ứng dụng trong kiến trúc ảo hóa ứng
chủ dụng.
Hình ảnh Một gói chứa tất cả các tệp cần thiết để chạy một vùng chứa.
Sự cách ly Khả năng tách biệt nhiều phiên bản phần mềm để mỗi phiên bản chỉ nhìn thấy và có
thể ảnh hưởng đến chính nó.
Dịch vụ vi mô Một tập hợp các thùng chứa phối hợp với nhau để tạo nên một ứng dụng.
Cách ly không Một hình thức cô lập giới hạn những tài nguyên mà vùng chứa có thể tương tác.
gian tên
Ảo hóa hệ điều hành Việc triển khai ảo giao diện hệ điều hành có thể được sử dụng để chạy các ứng
dụng được viết cho cùng một hệ điều hành. [từ 1]]
48
đ
n
b
Ất
p
cm NIST SP 800-190
Người soạn nhạc

Một công cụ cho phép các cá nhân DevOps hoặc tự động hóa hoạt động thay
mặt họ lấy hình ảnh từ cơ quan đăng ký, triển khai những hình ảnh đó vào vùng
chứa và quản lý các vùng chứa đang chạy. Người điều phối cũng chịu trách nhiệm
giám sát mức tiêu thụ tài nguyên vùng chứa, thực hiện công việc và tình trạng
máy trên các máy chủ.
Mạng lớp phủ Một thành phần mạng được xác định bằng phần mềm có trong hầu hết các bộ điều phối
có thể được sử dụng để cách ly giao tiếp giữa các ứng dụng chia sẻ cùng một
mạng vật lý.
Đăng ký Một dịch vụ cho phép các nhà phát triển dễ dàng lưu trữ hình ảnh khi chúng được
tạo, gắn thẻ và lập danh mục hình ảnh để nhận dạng và kiểm soát phiên bản
nhằm hỗ trợ khám phá và tái sử dụng cũng như tìm và tải xuống hình ảnh mà
người khác đã tạo.
Phân bổ Một cơ chế giới hạn lượng tài nguyên của máy chủ mà một vùng chứa
nguồn lực nhất định có thể tiêu thụ.
Máy ảo Một môi trường mô phỏng được tạo bằng ảo hóa. [từ 1]]
Ảo hóa Mô phỏng phần mềm và/hoặc phần cứng mà phần mềm khác chạy trên đó.
[từ 1]]
49
đ
n
b
Ất
p
cm NIST SP 800-190
Phụ lục E—Tài liệu tham khảo

[1] Ấn bản Đặc biệt của NIST (SP) 800-125, Hướng dẫn Bảo mật cho Công nghệ Ảo hóa Hoàn toàn,
Viện Tiêu chuẩn và Công nghệ Quốc gia, Gaithersburg, Maryland, tháng 1 năm 2011,
35pp. https://doi.org/10.6028/NIST.SP.800-125.
[2] Docker, https://www.docker.com/
[3] rkt, https://coreos.com/rkt/
[4] CoreOS Container Linux, https://coreos.com/os/docs/latest
[5] Dự án nguyên tử, http://www.projectatomic.io
[6] Hệ điều hành được tối ưu hóa cho vùng chứa của Google, https://cloud.google.com/container-optimized-
os/docs/
[7] Daemon sáng kiến container mở (OCID), https://github.com/kubernetes-

lồng ấp/cri-o
[số 8] Jenkins, https://jenkins.io
[9] TeamCity, https://www.jetbrains.com/teamcity/
[10] Cơ quan đăng ký vùng chứa Amazon EC2 (ECR), https://aws.amazon.com/ecr/
[11] Trung tâm Docker, https://hub.docker.com/
[12] Cơ quan đăng ký đáng tin cậy của Docker, https://hub.docker.com/r/docker/dtr/
[13] Cơ quan đăng ký container tại bến cảng, https://quay.io
[14] Kubernetes, https://kubernetes.io/
[15] Apache Mesos, http://mesos.apache.org/
[16] Docker Swarm, https://github.com/docker/swarm
[17] Ấn bản đặc biệt của NIST (SP) 800-154, Hướng dẫn về mối đe dọa hệ thống lấy dữ liệu làm trung tâm
Mô hình hóa (Dự thảo), Viện Tiêu chuẩn và Công nghệ Quốc gia, Gaithersburg, Maryland, tháng 3
năm 2016, 25pp. https://csrc.nist.gov/publications/detail/sp/800-

154/dự thảo.
[18] Hệ thống chấm điểm lỗ hổng bảo mật phổ biến v3.0: Tài liệu đặc tả, Diễn đàn dành cho các nhóm bảo
mật và ứng phó sự cố (FIRST). https://www.first.org/cvss/
specutions-document.
50
đ
n
bt
p
[19] Ấn bản đặc biệt (SP) 800-111 của NIST, Hướng dẫn về công nghệ mã hóa lưu trữ cho thiết bị
người dùng cuối, Viện Tiêu chuẩn và Công nghệ Quốc gia, Gaithersburg, Maryland, tháng 11
năm 2007, 40pp. https://doi.org/10.6028/NIST.SP.800-111.
[20] Điểm chuẩn Docker CIS, Trung tâm An ninh Internet (CIS).
https://www.cisecurity.org/benchmark/docker/.
Ấ
[21] Linux nâng cao bảo mật (SELinux), https://selinuxproject.org/page/Main_Page
[22] AppArmor, http://wiki.apparmor.net/index.php/Main_Page
[23] Ấn bản đặc biệt của NIST (SP) 800-123, Hướng dẫn về bảo mật máy chủ chung, Viện Tiêu chuẩn
và Công nghệ Quốc gia, Gaithersburg, Maryland, tháng 7 năm 2008, 53pp. https://doi.org/
10.6028/NIST.SP.800-123
[24] Ấn bản đặc biệt của NIST (SP) 800-164, Nguyên tắc về bảo mật bắt nguồn từ phần cứng trong
Thiết bị di động (Dự thảo), Viện Tiêu chuẩn và Công nghệ Quốc gia,
Gaithersburg, Maryland, tháng 10 năm 2012, 33pp.
https://csrc.nist.gov/publications/detail/sp/800-164/draft.
[25] Ấn bản đặc biệt của NIST (SP) 800-147, Nguyên tắc bảo vệ BIOS, Quốc gia
Viện Tiêu chuẩn và Công nghệ, Gaithersburg, Maryland, tháng 4 năm 2011, 26 trang.
https://doi.org/10.6028/NIST.SP.800-147.
[26] Ấn bản Đặc biệt (SP) 800-155 của NIST, Hướng dẫn Đo lường Tính toàn vẹn của BIOS (Dự
thảo), Viện Tiêu chuẩn và Công nghệ Quốc gia, Gaithersburg, Maryland, tháng 12 năm
2011, 47pp. https://csrc.nist.gov/publications/detail/sp/800-155/draft.
[27] Báo cáo nội bộ của NIST (IR) 7904, Định vị địa lý đáng tin cậy trên đám mây: Bằng chứng triển
khai khái niệm, Viện Tiêu chuẩn và Công nghệ Quốc gia, Gaithersburg, Maryland,
tháng 12 năm 2015, 59 trang https://doi.org/10.6028/NIST .IR.7904.
[28] Ấn bản Đặc biệt (SP) 800-61 Bản sửa đổi 2 của NIST, Hướng dẫn Xử lý Sự cố Bảo mật Máy
tính, Viện Tiêu chuẩn và Công nghệ Quốc gia, Gaithersburg, Maryland, tháng 8 năm
2012, 79 trang https://doi.org/10.6028/NIST. SP.800-61r2.
[29] Ấn bản Đặc biệt (SP) 800-53 Bản sửa đổi 4, Kiểm soát bảo mật và quyền riêng tư cho các tổ
chức và hệ thống thông tin liên bang, Viện Tiêu chuẩn và Công nghệ Quốc gia, Gaithersburg,
Maryland, tháng 4 năm 2013 (bao gồm các bản cập nhật kể từ ngày 15 tháng 1 năm 2014),
460 trang. https://doi.org/10.6028/NIST.SP.800-53r4.
[30] Khung cải thiện an ninh mạng cơ sở hạ tầng quan trọng Phiên bản 1.0,
Viện Tiêu chuẩn và Công nghệ Quốc gia, Gaithersburg, Maryland, ngày 12 tháng 2 năm
2014. https://www.nist.gov/document-3766.
51

NIST.SP.800-190 - tiếng việt

Uploaded by

Copyright:

Available Formats

You might also like

NIST.SP.800-190 - tiếng việt

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

NIST.SP.800-190 - tiếng việt

Uploaded by

Copyright:

Available Formats

Machine Translated by Google

Ấn phẩm đặc biệt của NIST 800-190

Hướng dẫn bảo mật vùng chứa ứng dụng

Ấn bản này được cung cấp miễn phí tại: https://

BẢO MẬT MÁY TÍNH

Ấn phẩm đặc biệt của NIST 800-190

Hướng dẫn bảo mật vùng chứa ứng dụng

Baton Rouge, Louisiana

An ninh mạng Scarfone

Ấn bản này được cung cấp miễn phí tại: https://

tháng 9 năm 2017

Bộ Thương mại Hoa Kỳ Wilbur

Viện Tiêu chuẩn và Công nghệ

Ấn phẩm này được cung cấp miễn phí tại:

Ý kiến về ấn phẩm này có thể được gửi tới:

Viện Tiêu chuẩn và Công nghệ

Báo cáo Công nghệ hệ thống máy tính

Thông tin nhãn hiệu

Tóm tắt điều hành

cho phép tăng cường phòng thủ theo chiều sâu.

Tóm tắt điều hành................................................................................. ................................................................. ... iv

1. Giới thiệu ................................................ ................................................................. .......... 1

1.1 Mục đích và phạm vi .................................................................... ................................... 1

1.2 Cấu trúc tài liệu................................................................................. ................................... 1

2 Giới thiệu về bộ chứa ứng dụng.................................................................. ................... 3

2.1 Các khái niệm cơ bản về ảo hóa ứng dụng và bộ chứa.................. 3

2.2 Bộ chứa và hệ điều hành máy chủ.................................................. ............ 5

2.3.3 Triển khai và quản lý container.................................................................. 10

2.4 Công dụng của thùng chứa .................................................... ................................... 11

3.1 Rủi ro về hình ảnh ................................................................. ...............................................................

13 3.1.1 Lỗ hổng hình ảnh.................................................. ................... 13

3.1.2 Lỗi cấu hình hình ảnh ................................................................. ................... 13

3.1.3 Phần mềm độc hại nhúng.................................................................. ...................... 14

3.1.4 Bí mật văn bản rõ ràng được nhúng .................................... ................... 14

3.1.5 Sử dụng hình ảnh không đáng tin cậy.................................................. .................... 14

3.2 Rủi ro đăng ký........... ................................................................. ................... 14

3.2.2 Hình ảnh cũ trong sổ đăng ký.................................................. ................... 14

3.2.3 Hạn chế xác thực và ủy quyền không đầy đủ .................... 14

3.3 Rủi ro của người điều phối .................................................... ................................... 15

3.3.1 Truy cập quản trị không giới hạn.................................................. .......... 15

3.3.2 Truy cập trái phép.................................................................. ...................... 15

3.3.5 Sự tin cậy của nút soạn thảo.................................................. ...................... 16

3.4 Rủi ro về container .................................................................... ................................... 16

3.4.1 Các lỗ hổng trong phần mềm thời gian chạy.................................................. 16

3.4.2 Truy cập mạng không giới hạn từ container................................................. 16

3.4.4 Lỗ hổng ứng dụng ................................................................. ................................. 17

3.4.5 Thùng chứa giả mạo ................................................................. ................................... 17

3.5.1 Bề mặt tấn công lớn................................................................. ................................. 17

3.5.2 Hạt nhân dùng chung ................................................................. ................................... 18

ảnh .................... ................................... 19

4.1.1 Lỗ hổng hình ảnh.................................................................. ................... 19

4.1.2 Lỗi cấu hình hình ảnh ................................................................. ................... 19

4.1.3 Phần mềm độc hại nhúng.................................................................. ................... 20

4.1.4 Bí mật văn bản rõ ràng được nhúng .................................... ................... 20

4.1.5 Sử dụng hình ảnh không đáng tin cậy.................................................. ................... 20

4.2.2 Hình ảnh cũ trong sổ đăng ký.................................................. ................... 21

4.2.3 Hạn chế xác thực và ủy quyền không đầy đủ .... 21

4.3.1 Truy cập quản trị không giới hạn.................................................. .......... 22