Machine Translated by Google

CHƯƠNG BA

An ninh cơ sở hạ tầng

TRONG CHƯƠNG NÀY, CHÚNG TÔI THẢO LUẬN CÁC MỐI ĐE DỌA, THÁCH THỨC VÀ HƯỚNG DẪN LIÊN QUAN ĐẾN việc bảo

mật cơ sở hạ tầng CNTT cốt lõi của tổ chức ở cấp độ mạng, máy chủ và ứng dụng.

Những người thực hành bảo mật thông tin thường sử dụng phương pháp này; do đó, nó dễ dàng quen

thuộc với họ. Chúng tôi thảo luận về bảo mật cơ sở hạ tầng này trong bối cảnh các mô hình cung

cấp dịch vụ SPI (SaaS, PaaS và IaaS). Các chuyên gia bảo mật phi thông tin được cảnh báo không

nên đánh đồng bảo mật cơ sở hạ tầng với bảo mật cơ sở hạ tầng dưới dạng dịch vụ (IaaS). Mặc dù

bảo mật cơ sở hạ tầng có liên quan nhiều hơn đến khách hàng của IaaS, nhưng cũng nên cân nhắc

tương tự đối với môi trường nền tảng dưới dạng dịch vụ (PaaS) và phần mềm dưới dạng dịch vụ

(SaaS) của nhà cung cấp, vì chúng có sự phân nhánh đối với khách hàng của bạn quản lý mối đe dọa,

rủi ro và tuân thủ. Một khía cạnh khác là mô hình kinh doanh đám mây (đám mây công cộng, riêng tư

và lai), trực giao với mô hình cung cấp dịch vụ SPI; những gì chúng tôi nhấn mạnh là sự liên quan

của các điểm thảo luận khi chúng áp dụng cho các đám mây công cộng và riêng tư. Khi thảo luận về

các đám mây công cộng, phạm vi bảo mật cơ sở hạ tầng được giới hạn ở các lớp cơ sở hạ tầng nằm

ngoài tầm kiểm soát của tổ chức và nằm trong tay các nhà cung cấp dịch vụ (nghĩa là khi trách

nhiệm đối với cơ sở hạ tầng an toàn được chuyển giao cho nhà cung cấp dịch vụ đám mây hoặc CSP,

dựa trên mô hình phân phối SPI). Thông tin trong chương này rất quan trọng đối với khách hàng để

hiểu được mức độ bảo mật mà CSP cung cấp và mức độ bảo mật mà bạn, khách hàng, chịu trách nhiệm

cung cấp.

35
Machine Translated by Google

Bảo mật cơ sở hạ tầng: Cấp độ mạng

Khi xem xét cấp độ mạng của bảo mật cơ sở hạ tầng, điều quan trọng là phải phân biệt giữa đám mây công cộng và đám mây

riêng, như chúng tôi đã giải thích trong Chương 2. Với đám mây riêng, không có cuộc tấn công mới, lỗ hổng hoặc thay đổi

rủi ro cụ thể nào đối với cấu trúc liên kết này nhân viên an toàn thông tin cần xem xét. Mặc dù kiến trúc CNTT của tổ chức

bạn có thể thay đổi khi triển khai đám mây riêng, nhưng cấu trúc liên kết mạng hiện tại của bạn có thể sẽ không thay đổi

đáng kể. Nếu bạn có một extranet riêng (ví dụ: dành cho khách hàng cao cấp hoặc đối tác chiến lược), vì các mục đích thực

tế, bạn có thể đã có sẵn cấu trúc liên kết mạng cho một đám mây riêng. Những cân nhắc về bảo mật mà bạn có ngày hôm nay

cũng áp dụng cho cơ sở hạ tầng đám mây riêng. Và các công cụ bảo mật bạn có sẵn (hoặc nên có sẵn) cũng cần thiết cho một

đám mây riêng và hoạt động theo cách tương tự. Hình 3-1 cho thấy sự tương đồng về cấu trúc liên kết giữa extranet an

toàn và đám mây riêng.

Tuy nhiên, nếu bạn chọn sử dụng các dịch vụ đám mây công cộng, việc thay đổi yêu cầu bảo mật sẽ yêu cầu thay đổi cấu

trúc liên kết mạng của bạn. Bạn phải giải quyết cách cấu trúc liên kết mạng hiện tại của bạn tương tác với cấu trúc

liên kết mạng của nhà cung cấp dịch vụ đám mây của bạn. Có bốn yếu tố rủi ro đáng kể trong trường hợp sử dụng này:

• Đảm bảo tính bảo mật và tính toàn vẹn của dữ liệu trong quá trình truyền đến và nhận của tổ chức bạn.

từ nhà cung cấp đám mây công cộng của bạn

• Đảm bảo kiểm soát truy cập phù hợp (xác thực, ủy quyền và kiểm toán) đối với bất kỳ

tài nguyên bạn đang sử dụng tại nhà cung cấp đám mây công cộng của mình

• Đảm bảo tính khả dụng của các tài nguyên truy cập Internet trong đám mây công cộng đang được tổ chức của bạn sử dụng

hoặc đã được các nhà cung cấp đám mây công cộng chỉ định cho tổ chức của bạn

• Thay thế mô hình vùng và tầng mạng đã thiết lập bằng tên miền

Chúng tôi sẽ thảo luận về từng yếu tố rủi ro này trong các phần tiếp theo.

Đảm bảo tính bảo mật và toàn vẹn của dữ liệu

Một số tài nguyên và dữ liệu trước đây chỉ giới hạn trong một mạng riêng hiện được hiển thị trên Internet và với một

mạng công cộng được chia sẻ thuộc về nhà cung cấp dịch vụ đám mây bên thứ ba.

36 CHƯƠNG BA
Machine Translated by Google

HÌNH 3-1. Cấu trúc liên kết mạng chung cho điện toán đám mây riêng

CƠ SỞ HẠ TẦNG AN NINH Y 37
Machine Translated by Google

Một ví dụ về các sự cố liên quan đến yếu tố rủi ro đầu tiên này là lỗ hổng bảo mật của Amazon Web Services (AWS) được

báo cáo vào tháng 12 năm 2008.* Trong một bài đăng trên blog, tác giả đã trình bày chi tiết một lỗ hổng trong thuật

toán chữ ký số được sử dụng khi “... thực hiện Truy vấn ( hay còn gọi là REST) tới Amazon SimpleDB, tới Amazon Elastic

Compute Cloud (EC2) hoặc tới Amazon Simple Queue Service (SQS) qua HTTP.” Mặc dù việc sử dụng HTTPS (thay vì HTTP) sẽ

giảm thiểu rủi ro về tính toàn vẹn, nhưng người dùng không sử dụng HTTPS (nhưng sử dụng HTTP) đã phải đối mặt với rủi

ro gia tăng là dữ liệu của họ có thể bị thay đổi trong quá trình chuyển tiếp mà họ không hề hay biết.

Đảm bảo kiểm soát truy cập thích hợp

Do một số tập hợp con của các tài nguyên này (hoặc thậm chí có thể là tất cả chúng) hiện được tiếp xúc với

Internet, nên một tổ chức sử dụng đám mây công cộng phải đối mặt với rủi ro gia tăng đáng kể đối với dữ liệu của mình.

Khả năng kiểm tra các hoạt động của mạng của nhà cung cấp dịch vụ đám mây của bạn (chưa nói đến việc tiến hành bất kỳ

hoạt động giám sát thời gian thực nào, chẳng hạn như trên mạng của chính bạn), ngay cả sau khi thực tế, có thể không tồn tại.

Bạn sẽ bị giảm quyền truy cập vào dữ liệu và nhật ký cấp mạng có liên quan, đồng thời hạn chế khả năng tiến hành điều

tra kỹ lưỡng và thu thập dữ liệu pháp y.

Một ví dụ về các vấn đề liên quan đến yếu tố rủi ro thứ hai này là vấn đề địa chỉ IP được sử dụng lại (chỉ định

lại). Nói chung, các nhà cung cấp đám mây không đủ "tuổi" địa chỉ IP khi chúng không còn cần thiết cho một khách

hàng. Các địa chỉ thường được chỉ định lại và sử dụng lại bởi các khách hàng khác khi chúng có sẵn. Từ quan điểm của

nhà cung cấp đám mây, điều này có ý nghĩa. Địa chỉ IP là một số lượng hữu hạn và một tài sản có thể lập hóa đơn. Tuy

nhiên, từ góc độ bảo mật của khách hàng, sự tồn tại lâu dài của các địa chỉ IP không còn được sử dụng có thể gây ra sự

cố. Một khách hàng không thể giả định rằng quyền truy cập mạng vào tài nguyên của mình bị chấm dứt khi phát hành địa

chỉ IP. Nhất thiết phải có thời gian trễ giữa việc thay đổi địa chỉ IP trong DNS và việc xóa địa chỉ đó trong bộ đệm

DNS. Có một khoảng thời gian trễ tương tự giữa khi địa chỉ vật lý (tức là MAC) được thay đổi trong bảng ARP và khi

địa chỉ ARP cũ bị xóa khỏi bộ đệm; một địa chỉ cũ vẫn tồn tại trong bộ đệm ARP cho đến khi chúng bị xóa. Điều này có

nghĩa là mặc dù các địa chỉ có thể đã bị thay đổi nhưng các địa chỉ cũ (hiện tại) vẫn có sẵn trong bộ đệm và do đó

chúng vẫn cho phép người dùng tiếp cận các tài nguyên được cho là không tồn tại này.

Gần đây, có nhiều báo cáo về sự cố với địa chỉ IP “không tuổi” tại một trong những nhà cung cấp dịch vụ đám mây lớn

nhất; đây có thể là động lực để AWS thông báo về khả năng IP đàn hồi của Amazon vào tháng 3 năm 2008.† (Với địa chỉ IP

đàn hồi, khách hàng được cung cấp một khối gồm năm địa chỉ IP có thể định tuyến để họ kiểm soát việc gán.) Ngoài ra,

theo

Simson Garfinkel:

* Vấn đề này đã được báo cáo trên blog của Colin Percival, “Daemonic Dispatches,” vào ngày 18 tháng 12 năm 2008.

Xem “Chữ ký AWS phiên bản 1 không an toàn”. Không có xác nhận công khai nào về vấn đề này trên trang web AWS cũng như

không có bất kỳ phản hồi công khai nào đối với bài đăng trên blog của Percival.

† Xem “Thông báo vùng khả dụng và địa chỉ IP đàn hồi cho Amazon EC2”. Mặc dù đã thông báo trong
Tháng 3 năm 2009, dịch vụ IP động có sẵn vào ngày 22 tháng 10 năm 2008.

38 CHƯƠNG BA
Machine Translated by Google

Một sự cố đang diễn ra riêng biệt với bộ cân bằng tải khiến chúng chấm dứt bất kỳ kết nối TCP/IP nào

chứa hơn 231 byte. Điều này có nghĩa là các đối tượng lớn hơn 2GB phải được lưu trữ vào S3 trong một số

giao dịch riêng lẻ, với mỗi giao dịch đó tham chiếu đến các phạm vi byte khác nhau của cùng một đối tượng.‡

Tuy nhiên, vấn đề về địa chỉ IP “không cũ” và truy cập mạng trái phép vào tài nguyên không chỉ áp dụng cho địa chỉ

IP có thể định tuyến (nghĩa là tài nguyên dự định có thể truy cập trực tiếp từ Internet). Vấn đề cũng áp dụng cho

các mạng nội bộ của nhà cung cấp đám mây để khách hàng sử dụng và gán địa chỉ IP không thể định tuyến. § Mặc dù

tài nguyên của bạn có thể không truy cập trực tiếp được từ Internet, nhưng vì mục đích quản lý, tài nguyên của

bạn phải có thể truy cập được trong mạng của nhà cung cấp đám mây thông qua địa chỉ riêng. (Mọi tài nguyên truy

cập công cộng/Internet cũng có một địa chỉ riêng.) Các khách hàng khác của nhà cung cấp dịch vụ đám mây của bạn có

thể không có ý tốt và có thể truy cập nội bộ tài nguyên của bạn thông qua mạng của nhà cung cấp dịch vụ đám mây.‖

Như đã báo cáo trên The Washington Post , AWS đã có vấn đề với việc lạm dụng tài nguyên ảnh hưởng đến công chúng

và các khách hàng khác.#

Một số sản phẩm mới xuất hiện trên thị trường* sẽ giúp giảm bớt vấn đề tái sử dụng địa chỉ IP, nhưng trừ khi các nhà

cung cấp dịch vụ đám mây cung cấp các sản phẩm này dưới dạng dịch vụ được quản lý, khách hàng sẽ phải trả tiền cho

một sản phẩm khác của bên thứ ba để giải quyết vấn đề mà các hoạt động của nhà cung cấp dịch vụ đám mây của họ đã tạo ra

cho họ.

Đảm bảo tính khả dụng của tài nguyên kết nối Internet

Sự phụ thuộc vào bảo mật mạng đã tăng lên do lượng dữ liệu tăng lên hoặc số lượng nhân viên tổ chức tăng

lên hiện phụ thuộc vào các thiết bị được lưu trữ bên ngoài để đảm bảo tính khả dụng của các tài nguyên do đám

mây cung cấp. Do đó, ba yếu tố rủi ro được liệt kê trong phần trước phải được tổ chức của bạn chấp nhận.

Chiếm quyền điều khiển tiền tố BGP† (nghĩa là làm sai lệch Thông tin khả năng tiếp cận của tầng mạng) là

một ví dụ điển hình về yếu tố rủi ro thứ ba này. Chiếm quyền điều khiển tiền tố liên quan đến việc thông báo một

‡ Xem Phần 3.3, “Đánh giá các dịch vụ điện toán lưới của Amazon: EC2, S3 và SQS,” của Simson L. Garfinkel;
TR-08-07, Nhóm Khoa học Máy tính, Đại học Harvard, Cambridge, Massachusetts.

§ Xem RFC 1918, “Phân bổ địa chỉ cho Internet riêng tư,” để biết thêm thông tin.

‖ Ví dụ: xem “Đặt địa chỉ phiên bản và bảo mật mạng” trong Amazon Elastic Compute Cloud
Hướng dẫn dành cho nhà phát triển (Phiên bản API 2008-12-01).

# “Amazon: Này những kẻ gửi thư rác, hãy rời khỏi đám mây của tôi!” đăng trên The Washington Post, ngày 1 tháng 7 năm 2008.

* Một ví dụ là VPN-Cubed của CohesiveFT, nhưng sản phẩm này không có sẵn dưới dạng dịch vụ của nhà cung cấp đám mây từ
hầu hết các nhà cung cấp đám mây—điều đó có nghĩa là còn có một giải pháp bên thứ ba khác để tích hợp vào môi trường
đám mây của bạn. Tuy nhiên, nhà cung cấp đám mây AWS cung cấp sản phẩm này dưới dạng dịch vụ.

† Giao thức cổng biên giới là một giao thức định tuyến liên miền được sử dụng trong lõi của Internet. Bạn có thể
tìm thêm thông tin về BGP trong RFC 4271, “A Border Gateway Protocol 4 (BGP-4).”

CƠ SỞ HẠ TẦNG AN NINH Y 39
Machine Translated by Google

hệ thống tự trị‡ không gian địa chỉ thuộc về người khác mà không có sự cho phép của cô ấy. Những thông

báo như vậy thường xảy ra do lỗi cấu hình, nhưng cấu hình sai đó vẫn có thể ảnh hưởng đến tính khả

dụng của các tài nguyên dựa trên đám mây của bạn. Theo một nghiên cứu được trình bày cho Nhóm các nhà

khai thác mạng Bắc Mỹ (NANOG) vào tháng 2 năm 2006, hàng trăm lỗi cấu hình sai như vậy xảy ra mỗi

tháng . một tuyến đường giả cho YouTube tới đối tác viễn thông của riêng mình, PCCW, có trụ sở tại Hồng

Kông. Mục đích là chặn YouTube ở Pakistan vì một số video được cho là báng bổ được lưu trữ trên trang

web. Kết quả là YouTube không khả dụng trên toàn cầu trong hai giờ.”

Ngoài cấu hình sai, còn có các cuộc tấn công có chủ ý. Mặc dù việc chiếm quyền điều khiển tiền tố do các

cuộc tấn công có chủ ý ít phổ biến hơn nhiều so với cấu hình sai nhưng nó vẫn xảy ra và có thể chặn

quyền truy cập vào dữ liệu. Theo nghiên cứu tương tự được trình bày cho NANOG, các cuộc tấn công xảy

ra ít hơn 100 lần mỗi tháng. Mặc dù các vụ tấn công tiền tố không phải là mới, nhưng con số tấn công

đó chắc chắn sẽ tăng lên và có thể là đáng kể, cùng với sự gia tăng của điện toán đám mây. Khi việc sử

dụng điện toán đám mây tăng lên, sự sẵn có của tài nguyên dựa trên đám mây sẽ tăng giá trị cho khách hàng.

Giá trị gia tăng đó đối với khách hàng đồng nghĩa với việc tăng nguy cơ hoạt động độc hại đe dọa

tính khả dụng đó.

Các cuộc tấn công DNS# là một ví dụ khác về các vấn đề liên quan đến yếu tố rủi ro thứ ba này. Trên

thực tế, có một số hình thức tấn công DNS đáng lo ngại liên quan đến điện toán đám mây.

Mặc dù các cuộc tấn công DNS không phải là mới và không liên quan trực tiếp đến việc sử dụng điện toán

đám mây, nhưng vấn đề với DNS và điện toán đám mây là sự gia tăng rủi ro của tổ chức ở cấp độ mạng do

truy vấn DNS bên ngoài tăng lên (làm giảm hiệu quả của “sự phân chia chân trời”. ”

cấu hình DNS*) cùng với số lượng nhân viên tổ chức tăng lên phụ thuộc nhiều hơn vào bảo mật mạng để

đảm bảo tính khả dụng của các tài nguyên do đám mây cung cấp đang được sử dụng.

‡ Theo RFC 1930, “Hướng dẫn tạo, lựa chọn và đăng ký hệ thống tự trị (AS),”, một hệ thống tự trị là một nhóm được
kết nối gồm một hoặc nhiều tiền tố IP do một hoặc nhiều nhà khai thác mạng điều hành. chính sách định tuyến đã xác
định.

§ Xem “Chiếm đoạt tiền tố tồn tại trong thời gian ngắn trên Internet” của Peter Boothe, James Hiebert và Randy Bush,
trình bày tại NANOG 36 vào tháng 2 năm 2006.

‖ Ví dụ: xem “Pakistan cắt quyền truy cập vào YouTube trên toàn thế giới” trên tờ The New York Times, ngày 26 tháng 2 năm 2008.

# DNS là viết tắt của Hệ thống tên miền. Xem RFC 1034, “Tên miền—Khái niệm và Cơ sở,” và
1035, “Tên miền—Việc triển khai và Đặc tả.”

* Điều đó không có nghĩa là các hệ thống DNS nội bộ hoàn toàn không bị tấn công—chỉ là chúng an toàn hơn
các hệ thống DNS bên ngoài và các truy vấn sử dụng chúng. Ví dụ: xem bài báo “Đường dẫn phân giải DNS bị hỏng: Sự
trỗi dậy của Cơ quan phân giải độc hại,” được viết bởi các thành viên của khoa của Viện Công nghệ Georgia.

40 CHƯƠNG BA
Machine Translated by Google

Mặc dù “Lỗi Kaminsky”† (CVE-2008-1447, “Lỗ hổng Entropy ổ cắm không đủ DNS”) đã thu hút hầu hết

sự chú ý về an ninh mạng trong năm 2008, nhưng các sự cố DNS khác cũng ảnh hưởng đến điện toán đám mây.

Không chỉ có các lỗ hổng trong giao thức DNS và trong quá trình triển khai DNS,‡ mà còn có các cuộc tấn

công đầu độc bộ đệm DNS khá phổ biến, theo đó máy chủ DNS bị lừa chấp nhận thông tin không chính xác. Mặc

dù nhiều người nghĩ rằng các cuộc tấn công đầu độc bộ đệm DNS đã bị dập tắt vài năm trước, nhưng điều đó

không đúng và những cuộc tấn công này vẫn còn là một vấn đề nghiêm trọng—đặc biệt là trong bối cảnh điện

toán đám mây.

Các biến thể của cuộc tấn công đầu độc bộ đệm cơ bản này bao gồm chuyển hướng máy chủ định danh (NS)

của miền đích, chuyển hướng bản ghi NS sang một miền mục tiêu khác và phản hồi trước NS thực (được

gọi là giả mạo DNS) .

Một ví dụ cuối cùng về các vấn đề liên quan đến yếu tố rủi ro thứ ba này là các cuộc tấn công từ chối

dịch vụ (DoS) và từ chối dịch vụ phân tán (DDoS). Một lần nữa, mặc dù các cuộc tấn công DoS/DDoS không

phải là mới và không liên quan trực tiếp đến việc sử dụng điện toán đám mây, nhưng vấn đề với các cuộc

tấn công này và điện toán đám mây là sự gia tăng rủi ro của một tổ chức ở cấp độ mạng do một số tài nguyên

bên ngoài được sử dụng nhiều hơn. mạng của tổ chức bạn. Ví dụ: tiếp tục có tin đồn về các cuộc tấn công

DDoS tiếp diễn trên AWS, khiến người dùng AWS không thể sử dụng dịch vụ trong nhiều giờ liền .

Tuy nhiên, khi sử dụng IaaS, nguy cơ bị tấn công DDoS không chỉ ở bên ngoài (tức là đối mặt với Internet).

Cũng có nguy cơ xảy ra cuộc tấn công DDoS nội bộ thông qua phần mạng của nhà cung cấp IaaS được khách

hàng sử dụng (tách biệt với mạng công ty của nhà cung cấp IaaS). Mạng nội bộ (không thể định tuyến) đó

là tài nguyên dùng chung, được khách hàng sử dụng để truy cập vào các phiên bản không công khai của họ

(ví dụ: Amazon Machine Images hoặc AMI) cũng như được nhà cung cấp sử dụng để quản lý mạng và tài

nguyên của họ (chẳng hạn như vật lý may chu ). Nếu tôi là một khách hàng lừa đảo, sẽ không có gì ngăn

cản tôi sử dụng quyền truy cập của khách hàng vào mạng nội bộ này để tìm và tấn công các khách hàng khác

hoặc cơ sở hạ tầng của nhà cung cấp IaaS—và nhà cung cấp có thể sẽ không có bất kỳ biện pháp kiểm soát

thám tử nào để thậm chí thông báo cho nó về một cuộc tấn công như vậy.

Biện pháp kiểm soát phòng ngừa duy nhất mà các khách hàng khác sẽ có là mức độ cứng rắn của các phiên

bản của họ (ví dụ: AMI) và liệu họ có đang tận dụng khả năng của nhà cung cấp để ngăn chặn tường lửa của

các nhóm phiên bản (ví dụ: AWS) hay không.

† Lỗi Kaminsky được đặt theo tên của nhà nghiên cứu bảo mật đã phát hiện ra vấn đề, Dan Kaminsky của IOActive.
Một lời giải thích phi kỹ thuật tốt về lỗi này và các nỗ lực giảm thiểu nó thông qua các nỗ lực với cộng đồng
nhà cung cấp có sẵn trong bài báo “Fresh Phish,” được xuất bản trong số tháng 10 năm 2008 của tạp chí IEEE's
Spectrum .

‡ Ví dụ: xem Ghi chú về lỗ hổng US-CERT VU#800113, “Lỗ hổng triển khai nhiều DNS
để đầu độc bộ nhớ đệm.” Kể từ ngày 31 tháng 12 năm 2008, Cơ sở dữ liệu dễ bị tổn thương quốc
gia liệt kê 312 lỗ hổng cho giao thức DNS và triển khai DNS. Cơ sở dữ liệu dễ bị tổn thương quốc gia được
tài trợ bởi US-CERT của Bộ An ninh Nội địa Hoa Kỳ và NIST.

§ Ví dụ: xem “Tin đồn: Lần nữa tấn công từ chối dịch vụ của Amazon,” được đăng ngày 6 tháng 6 năm 2008 tại
http://www.appscout.com/2008/06/rumor_amazon_hit_with_denialof.php.

TRONG CƠ SỞ HẠ TẦNG AN NINH Y 41

Machine Translated by Google

Thay thế mô hình đã thiết lập của các vùng và tầng mạng bằng tên miền

Mô hình cách ly đã thiết lập của các vùng và tầng mạng không còn tồn tại trong các đám mây IaaS và PaaS

công cộng. Trong nhiều năm, an ninh mạng đã dựa vào các vùng, chẳng hạn như mạng nội bộ so với mạng bên

ngoài và phát triển so với sản xuất, để phân tách lưu lượng mạng nhằm cải thiện an ninh. Mô hình này

dựa trên cơ chế loại trừ—chỉ những cá nhân và hệ thống có vai trò cụ thể mới có quyền truy cập vào các

khu vực cụ thể. Tương tự, các hệ thống trong một tầng cụ thể thường chỉ có quyền truy cập cụ thể trong

hoặc trên một tầng cụ thể. Ví dụ: các hệ thống trong tầng trình bày không được phép giao tiếp trực tiếp

với các hệ thống trong tầng cơ sở dữ liệu mà chỉ có thể giao tiếp với một hệ thống được ủy quyền trong

vùng ứng dụng. Các đám mây SaaS được xây dựng trên các đám mây IaaS hoặc PaaS công cộng có các đặc điểm

tương tự nhau. Tuy nhiên, SaaS công khai được xây dựng trên IaaS riêng (ví dụ: Salesforce.com) có thể

tuân theo mô hình cách ly truyền thống, nhưng thông tin cấu trúc liên kết đó thường không được chia

sẻ với khách hàng.

Mô hình truyền thống về vùng và tầng mạng đã được thay thế trong điện toán đám mây công cộng bằng “nhóm

bảo mật”, “miền bảo mật” hoặc “trung tâm dữ liệu ảo” có sự phân tách hợp lý giữa các tầng nhưng kém

chính xác hơn và khả năng bảo vệ kém hơn so với mô hình được thiết lập trước đây. người mẫu. Ví dụ:

tính năng nhóm bảo mật trong AWS cho phép các máy ảo (VM) của bạn truy cập lẫn nhau bằng tường lửa ảo

có khả năng lọc lưu lượng dựa trên địa chỉ IP (một địa chỉ cụ thể hoặc mạng con), loại gói (TCP, UDP ,

hoặc ICMP) và các cổng (hoặc một loạt các cổng). Tên miền được sử dụng trong các bối cảnh mạng khác

nhau và các mục đích đặt tên và địa chỉ dành riêng cho ứng dụng, dựa trên DNS. Ví dụ: Máy ứng dụng của

Google cung cấp một nhóm hợp lý các ứng dụng dựa trên các tên miền như mytestapp.test.mydomain.com và

myprodapp.prod.mydomain.com.

Trong mô hình các vùng và tầng mạng đã được thiết lập, không chỉ các hệ thống phát triển được tách

biệt về mặt logic với các hệ thống sản xuất ở cấp độ mạng, mà hai nhóm hệ thống này còn được tách

biệt về mặt vật lý ở cấp độ máy chủ (nghĩa là chúng chạy trên các máy chủ được phân tách về mặt vật lý

theo cách hợp lý). các vùng mạng riêng biệt). Tuy nhiên, với điện toán đám mây, sự tách biệt này không

còn tồn tại. Mô hình điện toán đám mây phân tách theo miền chỉ cung cấp phân tách hợp lý cho mục đích

đánh địa chỉ. Không còn bất kỳ sự tách biệt vật lý “bắt buộc” nào nữa, vì miền thử nghiệm và miền sản

xuất rất có thể nằm trên cùng một máy chủ vật lý.

Hơn nữa, sự phân tách mạng logic trước đây không còn tồn tại; phân tách logic hiện ở cấp máy chủ với

cả hai miền chạy trên cùng một máy chủ vật lý và chỉ được phân tách hợp lý bởi màn hình VM (siêu giám

sát).

Giảm nhẹ cấp độ mạng

Với các yếu tố được thảo luận trong các phần trước, bạn có thể làm gì để giảm thiểu các yếu tố

rủi ro gia tăng này? Đầu tiên, lưu ý rằng rủi ro cấp độ mạng tồn tại bất kể khía cạnh nào của dịch vụ

“điện toán đám mây” đang được sử dụng (ví dụ: phần mềm dưới dạng dịch vụ, nền tảng dưới dạng dịch vụ

hoặc cơ sở hạ tầng dưới dạng dịch vụ) . Do đó, việc xác định chính mức độ rủi ro không phải là *aaS

nào đang được sử dụng, mà là liệu tổ chức của bạn có ý định sử dụng hoặc đang sử dụng công khai hay không,

42 CHƯƠNG BA
Machine Translated by Google

đám mây riêng hoặc lai. Mặc dù một số đám mây IaaS cung cấp phân vùng mạng ảo, nhưng chúng có thể không phù

hợp với môi trường đám mây riêng nội bộ thực hiện kiểm tra trạng thái và các biện pháp bảo mật mạng khác.

Nếu tổ chức của bạn đủ lớn để cung cấp tài nguyên của một đám mây riêng, rủi ro của bạn sẽ giảm xuống—giả sử

bạn có một đám mây riêng thực sự bên trong mạng của mình. Trong một số trường hợp, đám mây riêng đặt tại cơ

sở của nhà cung cấp đám mây có thể giúp đáp ứng các yêu cầu bảo mật của bạn nhưng sẽ phụ thuộc vào khả năng

và mức độ trưởng thành của nhà cung cấp.

Bạn có thể giảm rủi ro bảo mật của mình bằng cách sử dụng mã hóa; cụ thể bằng cách sử dụng các triển khai mã

hóa đã được xác thực cho dữ liệu đang truyền. Chữ ký điện tử an toàn khiến việc giả mạo dữ liệu của bạn trở

nên khó khăn hơn nhiều, nếu không nói là không thể, và điều này đảm bảo tính toàn vẹn của dữ liệu.

Các vấn đề về tính khả dụng ở cấp độ mạng khó giảm thiểu hơn rất nhiều với điện toán đám mây—trừ khi

tổ chức của bạn đang sử dụng một đám mây riêng bên trong cấu trúc liên kết mạng của bạn. Ngay cả khi đám mây

riêng của bạn là mạng bên ngoài riêng tư (nghĩa là không chia sẻ) tại cơ sở của nhà cung cấp đám mây, bạn sẽ

phải đối mặt với rủi ro gia tăng ở cấp độ mạng. Một đám mây công cộng phải đối mặt với rủi ro lớn hơn. Nhưng

hãy giữ một số quan điểm ở đây — lớn hơn cái gì?

Ngay cả các doanh nghiệp lớn có nguồn lực đáng kể cũng phải đối mặt với những thách thức đáng kể ở cấp độ mạng

về bảo mật cơ sở hạ tầng. Những rủi ro liên quan đến điện toán đám mây có thực sự cao hơn những rủi ro mà các

doanh nghiệp đang phải đối mặt ngày nay không? Xem xét các mạng ngoại vi công cộng và riêng tư hiện có, đồng

thời tính đến các kết nối đối tác khi thực hiện so sánh như vậy. Đối với các doanh nghiệp lớn không có tài

nguyên đáng kể hoặc đối với các doanh nghiệp vừa và nhỏ (SMB), rủi ro khi sử dụng đám mây công cộng (giả sử

rằng các doanh nghiệp đó thiếu tài nguyên cần thiết cho đám mây riêng) có thực sự cao hơn rủi ro vốn có trong

cơ sở hạ tầng hiện tại của họ không? Trong nhiều trường hợp, câu trả lời có lẽ là không— không có mức độ rủi

ro cao hơn.

Bảng 3-1 liệt kê các biện pháp kiểm soát bảo mật ở cấp độ mạng.

BẢNG 3-1. Kiểm soát bảo mật ở cấp độ mạng

triển vọng mối đe dọa Thấp (ngoại trừ các cuộc tấn công DoS)

Kiểm soát phòng ngừa Kiểm soát truy cập mạng do nhà cung cấp cung cấp (ví dụ: tường lửa), mã hóa dữ liệu khi truyền (ví dụ: SSL,

IPSec)

điều khiển thám tử Tập hợp nhật ký sự kiện bảo mật do nhà cung cấp quản lý (quản lý sự kiện và sự cố bảo mật, hoặc

SIEM), hệ thống phát hiện xâm nhập/hệ thống ngăn chặn xâm nhập dựa trên mạng (IDS/IPS)

GHI CHÚ
Vì các khả năng của thám tử sẽ khác nhau giữa các nhà cung cấp, nên khách hàng nên đánh giá các nhà cung cấp về các

khả năng được trang bị.

CƠ SỞ HẠ TẦNG AN NINH Y 43
Machine Translated by Google

Bảo mật cơ sở hạ tầng: Cấp máy chủ

Khi xem xét bảo mật máy chủ và đánh giá rủi ro, bạn nên xem xét bối cảnh của các mô hình phân phối dịch

vụ đám mây (SaaS, PaaS và IaaS) và các mô hình triển khai (công khai, riêng tư và kết hợp). Mặc dù không

có mối đe dọa mới nào được biết đến đối với các máy chủ dành riêng cho điện toán đám mây, nhưng một số mối

đe dọa bảo mật ảo hóa—chẳng hạn như VM thoát, trôi cấu hình hệ thống và các mối đe dọa nội bộ bằng cách

kiểm soát truy cập yếu đối với trình ảo hóa—đã xâm nhập vào môi trường điện toán đám mây công cộng . Bản

chất năng động (độ co giãn) của điện toán đám mây có thể mang lại những thách thức hoạt động mới từ góc độ

quản lý bảo mật. Mô hình hoạt động thúc đẩy việc cung cấp nhanh chóng và các phiên bản tạm thời của máy ảo.

Do đó, việc quản lý các lỗ hổng và bản vá khó hơn nhiều so với việc chỉ quét, vì tốc độ thay đổi cao hơn

nhiều so với trong một trung tâm dữ liệu truyền thống.

Ngoài ra, thực tế là các đám mây khai thác sức mạnh của hàng nghìn nút tính toán, kết hợp với tính

đồng nhất của hệ điều hành được sử dụng bởi các máy chủ, có nghĩa là các mối đe dọa có thể được khuếch đại

nhanh chóng và dễ dàng—gọi đó là yếu tố “tốc độ tấn công” trong đám mây. Quan trọng hơn, bạn nên hiểu ranh

giới tin cậy và trách nhiệm đặt lên vai bạn để đảm bảo an toàn cho cơ sở hạ tầng máy chủ mà bạn quản lý.

Và bạn cũng nên so sánh tương tự với trách nhiệm của nhà cung cấp trong việc đảm bảo an toàn cho phần hạ

tầng máy chủ CSP

quản lý.

Bảo mật máy chủ SaaS và PaaS

Nói chung, CSP không chia sẻ công khai thông tin liên quan đến nền tảng máy chủ, hệ điều hành máy

chủ và các quy trình được áp dụng để bảo mật máy chủ, vì tin tặc có thể khai thác thông tin đó khi chúng

cố gắng xâm nhập vào dịch vụ đám mây. Do đó, trong bối cảnh các dịch vụ đám mây SaaS (ví dụ: Salesforce.com,

Workday.com) hoặc PaaS (ví dụ: Google App Engine, Force.com của Salesforce.com) , bảo mật máy chủ không rõ

ràng đối với khách hàng và trách nhiệm bảo mật máy chủ được chuyển xuống CSP. Để được CSP đảm bảo về tình

trạng bảo mật của máy chủ, bạn nên yêu cầu nhà cung cấp chia sẻ thông tin theo thỏa thuận không tiết lộ

(NDA) hoặc chỉ cần yêu cầu CSP chia sẻ thông tin qua khung đánh giá kiểm soát như SysTrust hoặc ISO 27002 .

Từ góc độ đảm bảo kiểm soát, CSP phải đảm bảo rằng các biện pháp kiểm soát phòng ngừa và phát hiện thích

hợp được áp dụng và sẽ phải đảm bảo điều tương tự thông qua đánh giá của bên thứ ba hoặc khung đánh giá

kiểu ISO 27002.

Do ảo hóa là công nghệ hỗ trợ chính giúp cải thiện việc sử dụng phần cứng máy chủ, trong số các lợi ích

khác, CSP thường sử dụng các nền tảng ảo hóa, bao gồm Xen và VMware hypervisor, trong kiến trúc nền tảng

máy tính chủ của họ. Bạn nên hiểu cách nhà cung cấp đang sử dụng công nghệ ảo hóa và quy trình của nhà cung

cấp để bảo mật lớp ảo hóa.

44 CHƯƠNG BA
Machine Translated by Google

Cả nền tảng PaaS và SaaS đều trừu tượng hóa và ẩn hệ điều hành máy chủ khỏi người dùng cuối bằng

lớp trừu tượng máy chủ. Một điểm khác biệt chính giữa PaaS và SaaS là khả năng truy cập của lớp

trừu tượng ẩn các dịch vụ hệ điều hành mà các ứng dụng sử dụng. Trong trường hợp của SaaS, lớp

trừu tượng không hiển thị với người dùng và chỉ dành cho nhà phát triển và nhân viên vận hành của

CSP, nơi người dùng PaaS được cấp quyền truy cập gián tiếp vào lớp trừu tượng của máy chủ dưới

dạng giao diện lập trình ứng dụng PaaS (API ) lần lượt tương tác với lớp trừu tượng máy chủ.

Nói tóm lại, nếu bạn là khách hàng của SaaS hoặc PaaS, thì bạn đang dựa vào CSP để cung cấp nền

tảng lưu trữ an toàn trên đó ứng dụng SaaS hoặc PaaS được phát triển và triển khai bởi CSP và

bạn, tương ứng.

Tóm lại, trách nhiệm bảo mật máy chủ trong các dịch vụ SaaS và PaaS được chuyển giao cho CSP.

Việc bạn không phải lo lắng về việc bảo vệ máy chủ khỏi các mối đe dọa bảo mật dựa trên máy chủ là

một lợi ích lớn từ quan điểm quản lý bảo mật và chi phí. Tuy nhiên, với tư cách là khách hàng,

bạn vẫn có rủi ro quản lý thông tin được lưu trữ trong các dịch vụ đám mây. Bạn có trách nhiệm

đạt được mức độ đảm bảo phù hợp về cách CSP quản lý vệ sinh bảo mật của máy chủ.

Bảo mật máy chủ IaaS

Không giống như PaaS và SaaS, khách hàng IaaS chịu trách nhiệm chính trong việc bảo mật

các máy chủ được cung cấp trên đám mây. Cho rằng hầu hết tất cả các dịch vụ IaaS hiện có

đều sử dụng ảo hóa ở lớp máy chủ, bảo mật máy chủ trong IaaS nên được phân loại như sau:

Bảo mật phần mềm ảo hóa

Lớp phần mềm nằm trên kim loại trần và cung cấp cho khách hàng khả năng tạo và hủy các

phiên bản ảo. Ảo hóa ở cấp máy chủ có thể được thực hiện bằng cách sử dụng bất kỳ mô hình ảo

hóa nào, bao gồm ảo hóa cấp hệ điều hành (bộ chứa Solaris, nhà tù BSD, Linux-VServer), ảo hóa

song song (kết hợp giữa phiên bản phần cứng và các phiên bản của Xen và VMware) hoặc phần

cứng ảo hóa dựa trên (Xen, VMware, Microsoft Hyper-V). Điều quan trọng là phải bảo mật lớp

phần mềm nằm giữa phần cứng và máy chủ ảo này. Trong dịch vụ IaaS công cộng, khách hàng không

có quyền truy cập vào lớp phần mềm này; nó chỉ được quản lý bởi CSP.

Hệ điều hành khách của khách hàng hoặc bảo mật máy chủ ảo

Phiên bản ảo của một hệ điều hành được cung cấp trên lớp ảo hóa và hiển thị cho khách hàng

từ Internet; ví dụ: các hương vị khác nhau của Linux, Microsoft và Solaris. Khách hàng có
toàn quyền truy cập vào máy chủ ảo.

Bảo mật phần mềm ảo hóa

Do CSP quản lý phần mềm ảo hóa nằm trên phần cứng nên khách hàng sẽ không thể nhìn thấy cũng như

không thể truy cập vào phần mềm này. Ảo hóa phần cứng hoặc hệ điều hành cho phép chia sẻ tài nguyên

phần cứng trên nhiều máy ảo khách mà không can thiệp lẫn nhau để bạn có thể chạy một số hệ điều

hành và ứng dụng cùng lúc một cách an toàn

CƠ SỞ HẠ TẦNG AN NINH Y 45
Machine Translated by Google

trên một máy tính duy nhất. Để đơn giản hóa, chúng tôi đã giả định rằng các dịch vụ IaaS đang sử dụng công nghệ “siêu

giám sát kim loại trần” (còn được gọi là siêu giám sát loại 1), chẳng hạn như VMware ESX, Xen, Oracle VM và Hyper-V của

Microsoft. Các trình ảo hóa này hỗ trợ nhiều hệ điều hành khách, bao gồm Microsoft Windows, nhiều “hương vị” Linux khác

nhau và OpenSolaris của Sun.

Cho rằng ảo hóa trình ảo hóa là thành phần thiết yếu đảm bảo việc phân vùng và cách ly các máy ảo của

khách hàng với nhau trong môi trường nhiều bên thuê, điều rất quan trọng là phải bảo vệ các trình ảo hóa khỏi

những người dùng trái phép. Một cuộc chạy đua vũ trang mới giữa tin tặc và người bảo vệ (CSP) trong lĩnh vực bảo mật ảo

hóa đã và đang diễn ra. Vì ảo hóa rất quan trọng đối với kiến trúc đám mây IaaS, nên bất kỳ cuộc tấn công nào có thể làm

tổn hại đến tính toàn vẹn của các ngăn sẽ là thảm họa đối với toàn bộ cơ sở khách hàng trên đám mây đó. Một sự cố gần đây

tại một công ty nhỏ có trụ sở tại Vương quốc Anh có tên là Vasserv.com là minh chứng cho mối đe dọa đối với bảo mật của

trình ảo hóa. Bằng cách khai thác lỗ hổng zero-day trong HyperVM, một ứng dụng ảo hóa do công ty có tên Lxlabs tạo ra, tin

tặc đã phá hủy 100.000 trang web do Vasserv.com lưu trữ. Lỗ hổng zero-day đã cho kẻ tấn công khả năng thực thi các lệnh

Unix nhạy cảm trên hệ thống, bao gồm rm -rf, buộc phải xóa đệ quy tất cả các tệp. Rõ ràng, chỉ vài ngày trước khi xảy ra

vụ xâm nhập, một người dùng ẩn danh đã đăng trên trang web của hacker có tên là milw0rm một danh sách dài các lỗ hổng

chưa được vá trong Kloxo, một bảng điều khiển lưu trữ tích hợp vào HyperVM. Tình hình còn tồi tệ hơn đối với khoảng 50%

khách hàng của Vaserv đã đăng ký dịch vụ không được quản lý, không bao gồm sao lưu dữ liệu. Vẫn chưa rõ liệu những chủ

sở hữu trang web đó có thể truy xuất tài khoản của họ hay không.

mất dữ liệu.

CSP nên thiết lập các biện pháp kiểm soát bảo mật cần thiết, bao gồm hạn chế quyền truy cập vật lý và logic vào trình ảo

hóa và các dạng lớp ảo hóa được sử dụng khác. Khách hàng IaaS nên hiểu các biện pháp kiểm soát quy trình bảo mật và công

nghệ do CSP thiết lập để bảo vệ trình ảo hóa. Điều này sẽ giúp bạn hiểu được sự tuân thủ và những thiếu sót liên quan đến

tiêu chuẩn bảo mật máy chủ, chính sách và tuân thủ quy định của bạn. Tuy nhiên, nhìn chung, các CSP thiếu tính minh bạch

trong lĩnh vực này và bạn có thể không có lựa chọn nào khác ngoài việc tin tưởng và tin tưởng các CSP sẽ cung cấp một

“hệ điều hành khách ảo hóa được bảo mật và cô lập”.

Các mối đe dọa đối với hypervisor

Tính toàn vẹn và tính khả dụng của trình ảo hóa là vô cùng quan trọng và là chìa khóa để đảm bảo tính toàn vẹn và

tính khả dụng của đám mây công cộng được xây dựng trên môi trường ảo hóa.

Một trình ảo hóa dễ bị tấn công có thể làm lộ tất cả các miền của người dùng cho những kẻ nội gián độc hại. Hơn nữa,

các trình ảo hóa có khả năng dễ bị tấn công lật đổ. Để minh họa lỗ hổng của lớp ảo hóa, một số thành viên của cộng đồng

nghiên cứu bảo mật đã trình diễn cuộc tấn công “Viên thuốc xanh” vào một trình ảo hóa. Trong Black Hat 2008 và Black Hat

DC 2009‖ Joanna Rutkowska, Alexander Tereshkin và Rafal Wojtczuk từ Invisible Things Lab đã trình bày một số cách để thỏa

hiệp ảo hóa của Xen.# Mặc dù Rutkowska và nhóm của cô ấy

‖ Mũ đen DC 2009.

46 CHƯƠNG BA
Machine Translated by Google

đã xác định các vấn đề với việc triển khai Xen, nhìn chung họ có vẻ khá tích cực về phương pháp Xen. Nhưng phần

trình diễn của họ cho thấy sự phức tạp của việc bảo mật các hệ thống ảo hóa và sự cần thiết của các phương pháp

tiếp cận mới để bảo vệ các trình ảo hóa khỏi các cuộc tấn công như vậy.

Do các lớp ảo hóa trong các đám mây công cộng phần lớn là nguồn đóng và độc quyền (mặc dù một số có thể sử dụng

dẫn xuất của phần mềm ảo hóa nguồn mở như Xen), mã nguồn của phần mềm được CSP sử dụng không có sẵn để cộng

đồng nghiên cứu bảo mật xem xét kỹ lưỡng. .

Bảo mật máy chủ ảo

Khách hàng của IaaS có toàn quyền truy cập vào các máy ảo khách ảo hóa được lưu trữ và cách ly với nhau bằng

công nghệ ảo hóa. Do đó, khách hàng chịu trách nhiệm bảo mật và quản lý bảo mật liên tục của máy ảo khách.

IaaS công cộng, chẳng hạn như Đám mây điện toán đàn hồi của Amazon (EC2), cung cấp API dịch vụ web để thực

hiện các chức năng quản lý như cung cấp, ngừng hoạt động và sao chép máy chủ ảo trên nền tảng IaaS. Các chức

năng quản lý hệ thống này, khi được phối hợp một cách thích hợp, có thể cung cấp khả năng co giãn để các nguồn

lực tăng hoặc giảm theo nhu cầu khối lượng công việc. Vòng đời động của máy chủ ảo có thể dẫn đến sự phức tạp nếu

quy trình quản lý máy chủ ảo không được tự động hóa theo quy trình thích hợp. Từ góc độ bề mặt tấn công, bất kỳ

ai trên Internet đều có thể truy cập máy chủ ảo (Windows, Solaris hoặc Linux), vì vậy cần thực hiện đủ các bước

giảm thiểu truy cập mạng để hạn chế quyền truy cập vào các phiên bản ảo. Thông thường, CSP chặn tất cả các cổng

truy cập vào máy chủ ảo và khuyến nghị khách hàng sử dụng cổng 22 (Secure Shell hoặc SSH) để quản lý các phiên bản

máy chủ ảo. API quản lý đám mây bổ sung thêm một lớp bề mặt tấn công khác và phải được đưa vào phạm vi bảo mật

máy chủ ảo trong đám mây công cộng. Một số mối đe dọa bảo mật máy chủ mới trong IaaS công khai bao gồm:

• Đánh cắp các khóa được sử dụng để truy cập và quản lý máy chủ (ví dụ: khóa riêng SSH)

• Tấn công các dịch vụ chưa được vá lỗi, dễ bị tổn thương đang lắng nghe trên các cổng tiêu chuẩn (ví dụ: FTP, NetBIOS,

SSH)

• Chiếm đoạt các tài khoản không được bảo mật đúng cách (nghĩa là mật khẩu yếu hoặc không có mật khẩu tiêu chuẩn

tài khoản)

• Tấn công các hệ thống không được bảo mật đúng cách bằng tường lửa máy chủ

• Triển khai Trojan được nhúng trong thành phần phần mềm trong VM hoặc trong VM

hình ảnh (hệ điều hành) chính nó

# Xem http://theinvisiblethings.blogspot.com/2008/08/our-xen-0wning-trilogy-highlights.html.

CƠ SỞ HẠ TẦNG AN NINH Y 47
Machine Translated by Google

Bảo vệ máy chủ ảo

Tính đơn giản của việc tự cung cấp các máy chủ ảo mới trên nền tảng IaaS tạo ra nguy cơ tạo ra các máy chủ ảo

không an toàn. Cấu hình an toàn theo mặc định cần phải được đảm bảo bằng cách tuân theo hoặc vượt quá các đường

cơ sở sẵn có của ngành.

Việc bảo mật máy chủ ảo trên đám mây yêu cầu các quy trình bảo mật vận hành mạnh mẽ cùng với việc tự động hóa các

quy trình. Dưới đây là một số khuyến nghị:

• Sử dụng cấu hình an toàn theo mặc định. Làm cứng hình ảnh của bạn và sử dụng hình ảnh làm cứng tiêu chuẩn để

khởi tạo máy ảo (hệ điều hành khách) trong đám mây công cộng. Phương pháp hay nhất cho các ứng dụng dựa trên

đám mây là xây dựng các hình ảnh VM tùy chỉnh chỉ có các khả năng và dịch vụ cần thiết để hỗ trợ ngăn xếp ứng

dụng. Việc giới hạn khả năng của ngăn xếp ứng dụng cơ bản không chỉ hạn chế bề mặt tấn công tổng thể của máy

chủ mà còn giảm đáng kể số lượng bản vá cần thiết để giữ an toàn cho ngăn xếp ứng dụng đó.

• Theo dõi kho hình ảnh VM và các phiên bản hệ điều hành được chuẩn bị cho dịch vụ lưu trữ đám mây.

Nhà cung cấp IaaS cung cấp một số hình ảnh VM này. Khi một hình ảnh ảo từ nhà cung cấp IaaS được sử dụng, nó

phải trải qua cùng một mức xác minh bảo mật và tăng cường cho các máy chủ trong doanh nghiệp. Giải pháp thay

thế tốt nhất là cung cấp hình ảnh của riêng bạn tuân thủ các tiêu chuẩn bảo mật giống như các máy chủ nội bộ

đáng tin cậy.

• Bảo vệ tính toàn vẹn của hình ảnh cứng khỏi sự truy cập trái phép.

• Bảo vệ các khóa riêng cần thiết để truy cập máy chủ trong đám mây công cộng.

• Nói chung, hãy cách ly các khóa giải mã khỏi đám mây lưu trữ dữ liệu—trừ khi

chúng cần thiết cho việc giải mã, và sau đó chỉ trong khoảng thời gian của hoạt động giải mã thực tế. Nếu ứng

dụng của bạn yêu cầu khóa để mã hóa và giải mã để xử lý dữ liệu liên tục, thì có thể không bảo vệ được khóa

vì khóa sẽ được sắp xếp cùng với ứng dụng.

• Không bao gồm thông tin đăng nhập xác thực trong hình ảnh ảo hóa của bạn ngoại trừ khóa để giải mã

khóa hệ thống tập tin.

• Không cho phép xác thực dựa trên mật khẩu để truy cập shell.

• Yêu cầu mật khẩu để truy cập sudo* hoặc dựa trên vai trò (ví dụ: Solaris, SELinux).

• Chạy tường lửa máy chủ và chỉ mở các cổng tối thiểu cần thiết để hỗ trợ các dịch vụ

trên một trường hợp.

• Chỉ chạy các dịch vụ được yêu cầu và tắt các dịch vụ không sử dụng (ví dụ: tắt FTP, dịch vụ in, dịch vụ tệp

mạng và dịch vụ cơ sở dữ liệu nếu chúng không được yêu cầu).

• Cài đặt IDS dựa trên máy chủ như OSSEC hoặc Samhain.

• Cho phép kiểm tra hệ thống và ghi nhật ký sự kiện, đồng thời ghi nhật ký các sự kiện bảo mật vào máy chủ nhật

ký chuyên dụng. Cô lập máy chủ nhật ký với khả năng bảo vệ an ninh cao hơn, bao gồm cả việc kiểm soát truy cập.

* Xem http://en.wikipedia.org/wiki/Sudo.

48 CHƯƠNG BA
Machine Translated by Google

• Nếu bạn nghi ngờ có sự thỏa hiệp, hãy tắt phiên bản, chụp nhanh khối lượng khối của bạn và sao lưu hệ thống

tập tin gốc. Bạn có thể thực hiện điều tra trên một hệ thống không thỏa hiệp sau này.

• Thiết lập quy trình vá ảnh trên đám mây—cả ngoại tuyến và khởi tạo

hình ảnh.

• Định kỳ xem lại nhật ký để phát hiện các hoạt động đáng ngờ.

Bảng 3-2 liệt kê các điều khiển bảo mật ở cấp máy chủ.

BẢNG 3-2. Kiểm soát bảo mật ở cấp máy chủ

triển vọng mối đe dọa Cao

kiểm soát phòng ngừa Tường lửa máy chủ, kiểm soát truy cập, vá lỗi, tăng cường hệ thống, xác thực mạnh

điều khiển thám tử Nhật ký sự kiện bảo mật, IDS/IPS dựa trên máy chủ

An ninh cơ sở hạ tầng: Cấp độ ứng dụng

Bảo mật ứng dụng hoặc phần mềm phải là một yếu tố quan trọng trong chương trình bảo mật của bạn. Hầu hết các

doanh nghiệp có chương trình bảo mật thông tin vẫn chưa thiết lập chương trình bảo mật ứng dụng để giải

quyết lĩnh vực này. Việc thiết kế và triển khai các ứng dụng được nhắm mục tiêu để triển khai trên nền tảng

đám mây sẽ yêu cầu các chương trình bảo mật ứng dụng hiện có đánh giá lại các tiêu chuẩn và thực tiễn hiện

tại. Phổ bảo mật ứng dụng bao gồm từ các ứng dụng một người dùng độc lập đến các ứng dụng thương mại điện tử

đa người dùng tinh vi được sử dụng bởi hàng triệu người dùng. Các ứng dụng web như hệ thống quản lý nội dung

(CMS), wiki, cổng thông tin, bảng thông báo và diễn đàn thảo luận được sử dụng bởi các tổ chức lớn và nhỏ. Một

số lượng lớn các tổ chức cũng phát triển và duy trì các ứng dụng web được xây dựng tùy chỉnh cho doanh nghiệp

của họ bằng cách sử dụng nhiều khung web khác nhau (PHP,† .NET,‡ J2EE,§ Ruby on Rails, Python, v.v.). Theo SANS,

cho đến năm 2007, rất ít tội phạm tấn công các trang web dễ bị tổn thương vì các vectơ tấn công khác có nhiều

khả năng dẫn đến lợi thế trong việc truy cập thông tin hoặc kinh tế trái phép. Tuy nhiên, những tiến bộ ngày càng

tăng trong cross-site scripting (XSS) và các cuộc tấn công khác đã chứng minh rằng bọn tội phạm đang tìm kiếm lợi

ích tài chính có thể khai thác các lỗ hổng do lỗi lập trình web như những cách mới để xâm nhập vào các tổ chức

quan trọng. Trong phần này, chúng tôi sẽ giới hạn thảo luận về bảo mật ứng dụng web: các ứng dụng web trên đám

mây được người dùng truy cập bằng trình duyệt Internet tiêu chuẩn, chẳng hạn như Firefox, Internet Explorer

hoặc Safari, từ bất kỳ máy tính nào được kết nối với Internet.

† Xem http://en.wikipedia.org/wiki/PHP.

‡ Xem http://msdn.microsoft.com/networkframework/.

§ Xem http://en.wikipedia.org/wiki/J2EE.

CƠ SỞ HẠ TẦNG AN NINH Y 49
Machine Translated by Google

Vì trình duyệt đã nổi lên như ứng dụng khách của người dùng cuối để truy cập các ứng dụng trên

đám mây, điều quan trọng là các chương trình bảo mật ứng dụng phải đưa bảo mật trình duyệt vào

phạm vi bảo mật ứng dụng. Họ cùng nhau xác định sức mạnh của bảo mật đám mây đầu cuối giúp bảo vệ

tính bảo mật, tính toàn vẹn và tính khả dụng của thông tin được xử lý bởi các dịch vụ đám mây.

Các mối đe dọa bảo mật cấp ứng dụng

Theo SANS,‖ các lỗ hổng ứng dụng web trong nguồn mở cũng như các ứng dụng được xây dựng tùy

chỉnh chiếm gần một nửa tổng số lỗ hổng được phát hiện từ tháng 11 năm 2006 đến tháng 10 năm 2007.

# Các mối đe dọa hiện tại khai thác các lỗ hổng ứng dụng nổi tiếng (ví dụ: OWASP Top 10; xem http://

www.owasp.org/index.php/Top_10_2007), bao gồm cross-site scripting (XSS), SQL injection, thực thi

tệp độc hại và các lỗ hổng khác do lỗi lập trình và lỗi thiết kế. Được trang bị kiến thức và công

cụ, tin tặc liên tục quét các ứng dụng web (có thể truy cập từ Internet) để tìm lỗ hổng ứng dụng.

Sau đó, chúng khai thác các lỗ hổng mà chúng phát hiện cho các hoạt động bất hợp pháp khác nhau

bao gồm gian lận tài chính, trộm cắp tài sản trí tuệ, chuyển đổi các trang web đáng tin cậy thành

máy chủ độc hại phục vụ khai thác phía máy khách và lừa đảo. Tất cả các khung web và tất cả các

loại ứng dụng web đều có nguy cơ mắc các lỗi bảo mật ứng dụng web, từ việc xác thực không đủ đến

lỗi logic ứng dụng.

Thực tiễn phổ biến là sử dụng kết hợp các biện pháp kiểm soát bảo mật vành đai và kiểm soát

truy cập dựa trên mạng và máy chủ để bảo vệ các ứng dụng web được triển khai trong môi trường

được kiểm soát chặt chẽ, bao gồm mạng nội bộ của công ty và đám mây riêng, khỏi các tin tặc

bên ngoài. Các ứng dụng web được xây dựng và triển khai trên nền tảng đám mây công cộng sẽ phải

chịu mức độ đe dọa cao, bị tin tặc tấn công và có khả năng bị lợi dụng để hỗ trợ các hoạt động lừa

đảo và bất hợp pháp. Trong mô hình mối đe dọa đó, các ứng dụng web được triển khai trong đám mây

công cộng (mô hình SPI) phải được thiết kế cho mô hình mối đe dọa Internet và bảo mật phải được

nhúng vào Vòng đời phát triển phần mềm (SDLC); xem Hình 3-2.

‖ Xem http://www.sans.org/about/sans.php.

# Xem http://www.sans.org/top20/.

50 CHƯƠNG BA
Machine Translated by Google

HÌNH 3-2. SDLC

DoS và EDoS
Ngoài ra, bạn nên biết về các cuộc tấn công DoS và DDoS cấp ứng dụng có khả năng làm gián đoạn

các dịch vụ đám mây trong một thời gian dài. Các cuộc tấn công này thường bắt nguồn từ các hệ thống

máy tính bị xâm nhập được kết nối với Internet (thông thường, tin tặc chiếm quyền điều khiển và

kiểm soát các máy tính bị nhiễm vi-rút/sâu/phần mềm độc hại và trong một số trường hợp là các máy

chủ mạnh mẽ không được bảo vệ). Các cuộc tấn công DoS cấp ứng dụng có thể biểu hiện dưới dạng tải

lại trang web có khối lượng lớn, yêu cầu dịch vụ web XML* (qua HTTP hoặc HTTPS) hoặc yêu cầu theo

giao thức cụ thể được dịch vụ đám mây hỗ trợ. Vì các yêu cầu độc hại này trộn lẫn với lưu lượng

truy cập hợp pháp nên rất khó để lọc có chọn lọc lưu lượng truy cập độc hại mà không ảnh hưởng đến

toàn bộ dịch vụ. Ví dụ: một cuộc tấn công DDoS vào Twitter vào ngày 6 tháng 8 năm 2009 đã khiến dịch

vụ ngừng hoạt động trong vài giờ (xem Hình 3-3).

* XML là viết tắt của eXtensible Markup Language; xem http://en.wikipedia.org/wiki/XML.

CƠ SỞ HẠ TẦNG AN NINH Y 51
Machine Translated by Google

HÌNH 3-3. Tấn công DDoS trên Twitter

Ngoài việc làm gián đoạn các dịch vụ đám mây, dẫn đến trải nghiệm người dùng kém và tác động ở cấp độ

dịch vụ, các cuộc tấn công DoS có thể nhanh chóng làm cạn kiệt ngân sách dịch vụ đám mây của công ty bạn. Các

cuộc tấn công DoS vào các ứng dụng đám mây trả tiền khi bạn sử dụng sẽ dẫn đến sự gia tăng đáng kể trong hóa

đơn tiện ích đám mây của bạn: bạn sẽ thấy mức sử dụng băng thông mạng, CPU và dung lượng lưu trữ tăng lên.

Kiểu tấn công này cũng được coi là từ chối tính bền vững về kinh tế (EDoS).†

Rào cản thấp đối với các doanh nghiệp vừa và nhỏ trong việc sử dụng điện toán đám mây cho mục đích sử dụng hợp

pháp cũng đang tạo điều kiện thuận lợi cho tin tặc. Bằng cách sử dụng các tài khoản đám mây bị tấn công hoặc

khai thác, tin tặc sẽ có thể liên kết các tài nguyên máy tính với nhau để đạt được số lượng máy tính khổng lồ

mà không phải trả bất kỳ chi phí cơ sở hạ tầng vốn nào. Trong một tương lai không xa, bạn có thể chứng kiến

các cuộc tấn công DoS được khởi chạy từ các đám mây IaaS hoặc PaaS nhằm vào các dịch vụ đám mây khác (các mô

hình đám mây thù địch và tấn công như vậy được mô tả là các đám mây đen).

Bảo mật người dùng cuối

Bạn, với tư cách là khách hàng của dịch vụ đám mây, chịu trách nhiệm về các nhiệm vụ bảo mật của người

dùng cuối—các quy trình bảo mật để bảo vệ PC được kết nối Internet của bạn—và thực hành “lướt web an toàn”.

Các biện pháp bảo vệ bao gồm sử dụng phần mềm bảo mật, chẳng hạn như phần mềm chống phần mềm độc hại, phần mềm

chống vi-rút, tường lửa cá nhân, bản vá bảo mật và phần mềm loại IPS trên máy tính được kết nối Internet của

bạn. Câu thần chú mới “trình duyệt là hệ điều hành của bạn” truyền tải một cách thích hợp thông điệp rằng

† Ví dụ, hãy xem http://rationalsecurity.typepad.com/blog/2009/01/a-couple-of-followups-on-my-edos-economic -denial-of-

sustainability-concept.html.

52 CHƯƠNG BA
Machine Translated by Google

các trình duyệt đã trở thành “hệ điều hành” phổ biến để sử dụng các dịch vụ đám mây. Tất cả các trình

duyệt Internet thường xuyên có lỗ hổng phần mềm khiến chúng dễ bị tấn công bảo mật bởi người dùng cuối.

Do đó, khuyến nghị của chúng tôi là khách hàng đám mây nên thực hiện các bước thích hợp để bảo vệ trình

duyệt khỏi các cuộc tấn công. Để đạt được bảo mật đầu cuối trong đám mây, điều cần thiết là khách hàng

phải duy trì trình duyệt sạch sẽ. Có nghĩa là giữ cho trình duyệt (ví dụ: Internet Explorer, Firefox,

Safari) được vá và cập nhật để giảm thiểu các mối đe dọa liên quan đến các lỗ hổng của trình duyệt. Hiện

tại, mặc dù các tiện ích bổ sung bảo mật của trình duyệt không có sẵn trên thị trường, nhưng người dùng

được khuyến khích thường xuyên kiểm tra trang web của nhà cung cấp trình duyệt để biết các bản cập nhật

bảo mật, sử dụng tính năng tự động cập nhật và cài đặt các bản vá kịp thời để duy trì bảo mật cho người

dùng cuối.‡

Ai chịu trách nhiệm về bảo mật ứng dụng web trong đám mây?

Tùy thuộc vào mô hình cung cấp dịch vụ đám mây (SPI) và thỏa thuận cấp độ dịch vụ (SLA), phạm vi trách

nhiệm bảo mật sẽ thuộc về cả khách hàng và nhà cung cấp đám mây. Điều quan trọng là phải hiểu trách nhiệm

bảo mật của bạn so với trách nhiệm của CSP. Trong bối cảnh đó, các cuộc khảo sát bảo mật gần đây đã nhấn

mạnh thực tế rằng sự thiếu minh bạch trong các biện pháp kiểm soát và thực tiễn bảo mật được CSP sử dụng

là một rào cản đối với việc áp dụng đám mây.

Để bắt đầu, khách hàng đám mây không có tính minh bạch cần thiết trong lĩnh vực lỗ hổng phần mềm trong

dịch vụ đám mây. Điều này ngăn khách hàng quản lý rủi ro hoạt động có thể đi kèm với các lỗ hổng. Hơn

nữa, bằng cách coi phần mềm của họ là độc quyền, CSP đang cản trở các nhà nghiên cứu bảo mật phân tích

phần mềm để tìm lỗi và lỗi bảo mật. (Ngoại lệ là các nhà cung cấp đám mây đang hoạt động trên phần mềm

nguồn mở.)

Do sự thiếu minh bạch này, khách hàng không còn lựa chọn nào khác ngoài việc tin tưởng CSP của họ tiết

lộ bất kỳ lỗ hổng mới nào có thể ảnh hưởng đến tính bảo mật, tính toàn vẹn hoặc tính khả dụng của ứng

dụng của họ. Ví dụ: kể từ tháng 3 năm 2009, không có nhà cung cấp IaaS, PaaS hoặc SaaS nổi bật nào tham

gia vào dự án Điểm yếu và Phơi nhiễm Chung (CVE). Trường hợp điển hình: AWS mất 7,5 tháng để khắc phục

một lỗ hổng mà Colin Percival đã báo cáo vào tháng 5 năm 2007. § Lỗ hổng này là một điểm yếu về mật mã

trong mã ký yêu cầu của Amazon đã ảnh hưởng đến các dịch vụ API cơ sở dữ liệu (SimpleDB) và API EC2 và

lỗ hổng này không được tạo ra công khai cho đến sau khi nó được khắc phục vào tháng 12 năm 2008. (Colin

thừa nhận rằng Amazon luôn xem xét vấn đề này một cách nghiêm túc và thời gian kéo dài đơn giản là do

khối lượng công việc lớn liên quan đến việc tung ra bản vá cho các dịch vụ bị ảnh hưởng.)

Khách hàng doanh nghiệp nên hiểu chính sách tiết lộ lỗ hổng bảo mật của dịch vụ đám mây và đưa yếu tố

đó vào đánh giá rủi ro CSP. Các phần sau thảo luận về bảo mật ứng dụng web trong bối cảnh mô hình cung cấp

dịch vụ đám mây SPI.

‡ Một tài liệu tham khảo tốt về bảo mật trình duyệt là Sổ tay bảo mật trình duyệt của Google .

§ Xem http://www.daemonology.net/blog/2008-12-18-AWS-signature-version-1-is-insecure.html.

CƠ SỞ HẠ TẦNG AN NINH Y 53
Machine Translated by Google

Bảo mật ứng dụng SaaS

Mô hình SaaS quy định rằng nhà cung cấp quản lý toàn bộ bộ ứng dụng được phân phối cho người dùng.

Do đó, các nhà cung cấp SaaS chịu trách nhiệm chính trong việc bảo mật các ứng dụng và thành phần mà

họ cung cấp cho khách hàng. Khách hàng thường chịu trách nhiệm về các chức năng bảo mật vận hành, bao

gồm quản lý người dùng và quyền truy cập khi được nhà cung cấp hỗ trợ. Thông thường, các khách hàng

tiềm năng, thường theo NDA, sẽ yêu cầu thông tin liên quan đến các biện pháp bảo mật của nhà cung

cấp. Thông tin này phải bao gồm thiết kế, kiến trúc, phát triển, thử nghiệm bảo mật ứng dụng hộp đen

trắng và quản lý phát hành.

Một số khách hàng đi đến mức thuê các nhà cung cấp bảo mật độc lập để thực hiện kiểm tra

thâm nhập (kiểm tra bảo mật hộp đen) các ứng dụng SaaS (với sự đồng ý của nhà cung cấp) để đạt được

sự đảm bảo một cách độc lập. Tuy nhiên, thử nghiệm thâm nhập có thể tốn kém và không phải tất cả các

nhà cung cấp đều đồng ý với loại xác minh này.

Cần chú ý thêm đến các tính năng kiểm soát truy cập và xác thực do SaaS CSP cung cấp. Thông thường,

đó là biện pháp kiểm soát bảo mật duy nhất có sẵn để quản lý rủi ro đối với thông tin.

Hầu hết các dịch vụ, kể cả những dịch vụ từ Salesforce.com và Google, đều cung cấp công

cụ giao diện người dùng quản trị dựa trên web để quản lý xác thực và kiểm soát truy cập của

ứng dụng. Một số ứng dụng SaaS, chẳng hạn như Google Apps, có các tính năng tích hợp sẵn mà người

dùng cuối có thể gọi để gán đặc quyền đọc và ghi cho người dùng khác. Tuy nhiên, các tính năng quản

lý đặc quyền có thể không phải là quyền truy cập nâng cao, chi tiết và có thể có các điểm yếu không

phù hợp với tiêu chuẩn kiểm soát quyền truy cập của tổ chức bạn. Một ví dụ về vấn đề này là cơ chế mà

Google Tài liệu sử dụng để xử lý hình ảnh được nhúng trong tài liệu, cũng như các đặc quyền truy cập

vào các phiên bản cũ hơn của tài liệu. Rõ ràng là hình ảnh nhúng được lưu trữ trong Google Tài liệu

không được bảo vệ giống như cách tài liệu được bảo vệ bằng các điều khiển chia sẻ. Điều đó có nghĩa

là nếu bạn đã chia sẻ tài liệu có chứa hình ảnh được nhúng, người khác sẽ luôn có thể xem những hình

ảnh đó ngay cả khi bạn đã ngừng chia sẻ tài liệu. Một blogger‖ đã phát hiện ra sự cố kiểm soát truy

cập này và khiến Google chú ý. Mặc dù Google đã thừa nhận sự cố, nhưng phản hồi của Google cho thấy

rằng họ tin rằng # những lo ngại đó không gây ra rủi ro bảo mật đáng kể cho người dùng.

Một sự cố khác liên quan đến Google Tài liệu là một trục trặc về quyền riêng tư* đã chia sẻ quyền

truy cập một cách không thích hợp vào một phần nhỏ (Google tuyên bố 0,05% tài liệu bị ảnh hưởng) đối

với các tài liệu trình bày và xử lý văn bản được lưu trữ trên dịch vụ đám mây Google Apps của mình.

Mặc dù các tài liệu chỉ được chia sẻ với những người mà người dùng Google Tài liệu đã chia sẻ tài

liệu, chứ không phải với cả thế giới nói chung, vấn đề cho thấy sự cần thiết phải đánh giá và hiểu các

cơ chế kiểm soát truy cập dành riêng cho đám mây.

‖ Sự cố kiểm soát truy cập Google Tài liệu: http://peekay.org/2009/03/26/security-issues-with-google-docs/.

# Phản hồi kiểm soát truy cập Google Tài liệu đối với sự cố điểm yếu: http://googledocs.blogspot.com/2009/03/just-to

-làm rõ.html.

* Trục trặc về quyền riêng tư của Google Tài liệu: http://www.techcrunch.com/2009/03/07/huge-google-privacy-blunder-shares-

your -docs-without-permission/.

54 CHƯƠNG BA
Machine Translated by Google

Khách hàng trên đám mây nên cố gắng hiểu các cơ chế kiểm soát quyền truy cập dành riêng cho đám mây

—bao gồm hỗ trợ xác thực mạnh và quản lý đặc quyền dựa trên vai trò và chức năng của người dùng—đồng thời

thực hiện các bước cần thiết để bảo vệ thông tin được lưu trữ trên đám mây. Các biện pháp kiểm soát bổ

sung nên được triển khai để quản lý quyền truy cập đặc quyền vào công cụ quản trị SaaS và thực thi phân

tách nhiệm vụ để bảo vệ ứng dụng khỏi các mối đe dọa từ nội bộ. Để phù hợp với các thông lệ tiêu chuẩn bảo

mật, khách hàng nên triển khai chính sách mật khẩu mạnh—chính sách này buộc người dùng phải chọn mật khẩu

mạnh khi xác thực ứng dụng.†

Thông lệ phổ biến đối với các nhà cung cấp SaaS là trộn lẫn dữ liệu khách hàng của họ (có cấu trúc và không

có cấu trúc) trong một kho lưu trữ dữ liệu ảo duy nhất và dựa vào việc gắn thẻ dữ liệu để thực thi cách ly

giữa dữ liệu khách hàng. Trong mô hình lưu trữ dữ liệu nhiều bên thuê đó, nơi mã hóa có thể không khả thi

do quản lý khóa và các rào cản thiết kế khác, dữ liệu được gắn thẻ và lưu trữ với một mã định danh khách

hàng duy nhất. Thẻ dữ liệu duy nhất này giúp logic nghiệp vụ được nhúng trong lớp ứng dụng có thể thực thi

cách ly giữa các khách hàng khi dữ liệu được xử lý. Có thể hình dung rằng lớp ứng dụng thực thi sự cô lập

này có thể trở nên dễ bị tấn công trong quá trình nâng cấp phần mềm của CSP. Do đó, khách hàng nên hiểu kiến

trúc lưu trữ dữ liệu ảo và các cơ chế phòng ngừa mà các nhà cung cấp SaaS sử dụng để đảm bảo việc ngăn

cách và cách ly cần thiết trong môi trường nhiều bên thuê ảo.

Các nhà cung cấp SaaS lâu đời, chẳng hạn như Salesforce.com, Microsoft và Google, được biết là đầu tư vào

bảo mật phần mềm và thực hành đảm bảo bảo mật như một phần trong SDLC của họ. Tuy nhiên, do không có tiêu

chuẩn ngành để đánh giá tính bảo mật của phần mềm nên gần như không thể đánh giá các nhà cung cấp theo tiêu

chuẩn cơ sở.‡

Bảng 3-3 liệt kê các biện pháp kiểm soát bảo mật ở cấp ứng dụng.

BẢNG 3-3. Kiểm soát bảo mật ở cấp ứng dụng

triển vọng mối đe dọa Trung bình

kiểm soát phòng ngừa Quản lý danh tính, đánh giá kiểm soát truy cập, tăng cường trình duyệt với các bản vá mới nhất,

xác thực đa yếu tố thông qua xác thực được ủy quyền, các biện pháp bảo mật điểm cuối bao gồm

chống vi-rút và IPS

điều khiển thám tử Lịch sử đăng nhập và các báo cáo có sẵn từ các nhà cung cấp SaaS

† Xem Chương 5 để biết các cách tăng cường xác thực, bao gồm xác thực được ủy quyền và quyền truy cập

sự quản lý.

‡ Tiêu chuẩn bảo mật dữ liệu ứng dụng thanh toán (PA-DSS) chỉ áp dụng cho các tổ chức lưu trữ, xử lý hoặc truyền dữ liệu chủ thẻ—với hướng dẫn dành

cho nhà phát triển phần mềm và nhà sản xuất ứng dụng cũng như thiết bị được sử dụng trong các giao dịch đó.

CƠ SỞ HẠ TẦNG AN NINH Y 55
Machine Translated by Google

Bảo mật ứng dụng PaaS

Các nhà cung cấp PaaS thường thuộc hai loại chính sau:

• Nhà cung cấp phần mềm (ví dụ: Bungee, Etelos, GigaSpaces, Eucalyptus)

• CSP (ví dụ: Google App Engine, Salesforce.com's Force.com, Microsoft Azure, Intuit

QuickBase)

Các tổ chức đánh giá đám mây riêng có thể sử dụng phần mềm PaaS để xây dựng giải pháp cho tiêu

dùng nội bộ. Hiện tại, không có đám mây công cộng lớn nào được biết là đang sử dụng phần mềm PaaS

thương mại có sẵn hoặc mã nguồn mở như Eucalyptus (Tuy nhiên, Eucalyptus cung cấp một đám mây thí

điểm thử nghiệm hạn chế cho các nhà phát triển tại Eucalyptus.com, §) . Do đó, với giai đoạn triển

khai PaaS mới bắt đầu, chúng ta sẽ không thảo luận về bảo mật phần mềm của phần mềm PaaS độc lập trong

chương này. Tuy nhiên, các tổ chức đánh giá phần mềm PaaS nên thực hiện đánh giá rủi ro và áp dụng

tiêu chuẩn bảo mật phần mềm tương tự như mua bất kỳ phần mềm doanh nghiệp nào.

Theo định nghĩa, đám mây PaaS (công khai hoặc riêng tư) cung cấp một môi trường tích hợp để thiết

kế, phát triển, thử nghiệm, triển khai và hỗ trợ các ứng dụng tùy chỉnh được phát triển bằng ngôn ngữ

mà nền tảng hỗ trợ. Bảo mật ứng dụng PaaS bao gồm hai lớp phần mềm:

• Bảo mật của chính nền tảng PaaS (tức là công cụ thời gian chạy)

• Bảo mật các ứng dụng của khách hàng được triển khai trên nền tảng PaaS

Nói chung, các CSP PaaS (ví dụ: Google, Microsoft và Force.com) chịu trách nhiệm bảo mật ngăn xếp

phần mềm nền tảng bao gồm công cụ thời gian chạy chạy các ứng dụng của khách hàng. Vì các ứng dụng

PaaS có thể sử dụng các ứng dụng, thành phần hoặc dịch vụ web của bên thứ ba nên nhà cung cấp ứng dụng

bên thứ ba có thể chịu trách nhiệm bảo mật các dịch vụ của họ.

Do đó, khách hàng nên hiểu sự phụ thuộc của ứng dụng của họ vào tất cả các dịch vụ và đánh giá rủi ro

liên quan đến các nhà cung cấp dịch vụ bên thứ ba. Cho đến nay, các CSP vẫn miễn cưỡng chia sẻ thông

tin liên quan đến bảo mật nền tảng với lập luận rằng thông tin bảo mật đó có thể mang lại lợi thế cho

tin tặc. Tuy nhiên, khách hàng doanh nghiệp nên yêu cầu sự minh bạch từ CSP và tìm kiếm thông tin cần

thiết để thực hiện đánh giá rủi ro và quản lý bảo mật liên tục.

Bộ chứa ứng dụng PaaS

Trong mô hình cung cấp dịch vụ PaaS nhiều bên thuê, các nguyên lý bảo mật cốt lõi là ngăn chặn và cách

ly các ứng dụng nhiều bên thuê với nhau. Trong mô hình đó, quyền truy cập vào dữ liệu của bạn sẽ bị

hạn chế đối với người dùng doanh nghiệp của bạn và đối với các ứng dụng mà bạn sở hữu và quản lý. Mô

hình bảo mật của công cụ thời gian chạy nền tảng PaaS là tài sản trí tuệ của CSP và điều cần thiết là

cung cấp kiến trúc “hộp cát” trong một mô hình điện toán nhiều bên thuê. Do đó, đặc tính hộp cát của

công cụ thời gian chạy nền tảng là trọng tâm trong việc duy trì

§ Xem http://open.eucalyptus.com/wiki/EucalyptusPublicCloud.

56 CHƯƠNG BA
Machine Translated by Google

tính bảo mật và tính toàn vẹn của ứng dụng của bạn được triển khai trong PaaS. CSP chịu trách nhiệm giám

sát các lỗi và lỗ hổng bảo mật mới có thể được sử dụng để khai thác nền tảng PaaS và thoát ra khỏi kiến

trúc hộp cát. Loại tình huống này là trường hợp xấu nhất đối với dịch vụ PaaS; ý nghĩa bảo mật đối với

thông tin nhạy cảm của khách hàng là điều không mong muốn và có thể gây tổn hại rất lớn cho doanh nghiệp của

bạn. Do đó, khách hàng doanh nghiệp nên tìm kiếm thông tin từ CSP về kiến trúc ngăn chặn và cách ly của dịch
vụ PaaS.

Giám sát an ninh mạng và máy chủ bên ngoài nền tảng PaaS cũng là trách nhiệm của nhà cung cấp đám mây PaaS

(nghĩa là giám sát mạng dùng chung và cơ sở hạ tầng hệ thống lưu trữ các ứng dụng của khách hàng). Khách

hàng PaaS nên hiểu cách PaaS CSP đang quản lý nền tảng của họ, bao gồm cập nhật công cụ thời gian chạy và

thay đổi, phát hành và vá lỗi

sự quản lý.

Bảo mật ứng dụng do khách hàng triển khai

Các nhà phát triển PaaS cần làm quen với các API cụ thể để triển khai và quản lý các mô-đun phần mềm thực

thi kiểm soát bảo mật. Ngoài ra, do API là duy nhất cho dịch vụ đám mây PaaS, các nhà phát triển bắt buộc

phải làm quen với các tính năng bảo mật dành riêng cho nền tảng— có sẵn cho họ ở dạng đối tượng bảo mật và

dịch vụ web để định cấu hình kiểm soát xác thực và ủy quyền trong ứng dụng. Khi nói đến thiết kế API PaaS,

hiện tại không có tiêu chuẩn nào khả dụng cũng như không có bất kỳ nỗ lực phối hợp nào của CSP để phát

triển API phổ biến và nhất quán trên các đám mây—và điều đó làm cho việc chuyển ứng dụng qua các đám mây

PaaS trở thành một nhiệm vụ to lớn. Hiện tại, Google App Engine chỉ hỗ trợ Python và Java, còn Force.com của

Salesforce.com chỉ hỗ trợ một ngôn ngữ độc quyền có tên là Apex. (Apex khác với các ngôn ngữ như C++, Java

và .NET. Không giống như các ngôn ngữ đó, Apex bị giới hạn hơn nhiều về phạm vi và dành riêng cho việc xây

dựng các ứng dụng kinh doanh trên nền tảng Force.com.)

Về vấn đề này, các dịch vụ đám mây có tiềm năng giữ chân khách hàng mạnh mẽ hơn so với cấp phép phần

mềm truyền thống. Việc thiếu một tiêu chuẩn API có sự phân nhánh cho cả quản lý bảo mật và tính di động của

các ứng dụng trên đám mây.

Các nhà phát triển nên mong đợi các CSP cung cấp một tập hợp các tính năng bảo mật, bao gồm xác thực người

dùng, đăng nhập một lần (SSO) bằng cách sử dụng liên kết, ủy quyền (quản lý đặc quyền) và hỗ trợ SSL hoặc

TLS, được cung cấp qua API. Hiện tại, không có tiêu chuẩn quản lý bảo mật PaaS: CSP có các mô hình bảo mật

duy nhất và các tính năng bảo mật sẽ khác nhau giữa các nhà cung cấp.

Trong trường hợp của Google App Engine, nhà phát triển sử dụng các đối tượng Python hoặc Java có thể định

cấu hình hồ sơ người dùng và chọn HTTPS làm giao thức truyền tải. Tương tự, Force.com cung cấp một API

Apex để định cấu hình các tham số bảo mật, thao tác các cấu hình thời gian chạy khác nhau và chỉ định các

cổng TCP nhất định cho các tương tác kiểu kết nối giữa ứng dụng với ứng dụng bằng cách sử dụng các đối

tượng Apex.‖

‖ Ví dụ: xem http://www.salesforce.com/us/developer/docs/api/Content/sforce_api_concepts_security.htm.

CƠ SỞ HẠ TẦNG AN NINH Y 57
Machine Translated by Google

Dựa trên đánh giá của chúng tôi về các CSP PaaS chính, các tính năng bảo mật khả dụng cho các ứng dụng

PaaS bị giới hạn ở cấu hình bảo mật cơ bản—cấu hình SSL, quản lý đặc quyền cơ bản và xác thực người dùng bằng

cách sử dụng kho nhận dạng của nhà cung cấp. Chỉ trong một vài trường hợp, liên kết người dùng được hỗ trợ bằng

Ngôn ngữ đánh dấu xác nhận bảo mật (SAML).

Bảng 3-4 liệt kê các biện pháp kiểm soát bảo mật áp dụng cho các ứng dụng PaaS.

BẢNG 3-4. Kiểm soát bảo mật áp dụng cho các ứng dụng PaaS

triển vọng mối đe dọa Trung bình

kiểm soát phòng ngừa Xác thực người dùng, quản lý tài khoản, tăng cường trình duyệt với các bản vá lỗi mới nhất, thiết bị đầu cuối

các biện pháp bảo mật bao gồm chống vi-rút và IPS

điều khiển thám tử Quét lỗ hổng ứng dụng

Bảo mật ứng dụng IaaS

Các nhà cung cấp đám mây IaaS (ví dụ: Amazon EC2, GoGrid và Joyent) coi các ứng dụng trên phiên bản ảo của

khách hàng là hộp đen và do đó hoàn toàn không biết gì về hoạt động và quản lý ứng dụng của khách hàng. Toàn

bộ ngăn xếp—ứng dụng của khách hàng, nền tảng ứng dụng thời gian chạy (Java, .NET, PHP, Ruby on Rails, v.v.),

v.v.— chạy trên máy chủ ảo của khách hàng và được khách hàng triển khai và quản lý. Để đạt được mục tiêu đó, khách

hàng có toàn bộ trách nhiệm bảo mật cho các ứng dụng của họ được triển khai trên đám mây IaaS.

Do đó, khách hàng không nên mong đợi bất kỳ hỗ trợ bảo mật ứng dụng nào từ CSP ngoài hướng dẫn cơ bản và các tính

năng liên quan đến chính sách tường lửa có thể ảnh hưởng đến giao tiếp của ứng dụng với các ứng dụng, người dùng

hoặc dịch vụ khác trong hoặc ngoài đám mây.

Các ứng dụng web được triển khai trong đám mây công cộng phải được thiết kế cho mô hình mối đe dọa Internet, được

nhúng với các biện pháp đối phó bảo mật tiêu chuẩn chống lại các lỗ hổng web phổ biến (ví dụ: Top 10 của OWASP). Để

tuân thủ các phương pháp phát triển bảo mật chung, chúng cũng phải được kiểm tra định kỳ để phát hiện các lỗ hổng

và quan trọng nhất là bảo mật phải được nhúng vào SDLC. Khách hàng hoàn toàn chịu trách nhiệm giữ cho các ứng dụng

và nền tảng thời gian chạy của họ được vá lỗi để bảo vệ hệ thống khỏi phần mềm độc hại và tin tặc đang quét các lỗ

hổng để giành quyền truy cập trái phép vào dữ liệu của họ trên đám mây. Bạn nên thiết kế và triển khai các ứng dụng

có mô hình thời gian chạy “ít đặc quyền nhất” (ví dụ: định cấu hình ứng dụng để chạy bằng tài khoản có đặc quyền thấp

hơn).

Các nhà phát triển viết ứng dụng cho đám mây IaaS phải triển khai các tính năng của riêng họ để xử lý xác thực và

ủy quyền. Để phù hợp với thực tiễn quản lý danh tính doanh nghiệp, các ứng dụng đám mây phải được thiết kế để tận

dụng các tính năng dịch vụ xác thực được ủy quyền được hỗ trợ bởi Nhà cung cấp danh tính doanh nghiệp (ví dụ:

OpenSSO, Oracle IAM, IBM, CA) hoặc nhà cung cấp dịch vụ nhận dạng bên thứ ba (ví dụ: Ping Identity, Giản lược,

TriCipher). Bất kỳ triển khai tùy chỉnh nào của các tính năng Xác thực, Ủy quyền và Kế toán (AAA) đều có thể

58 CHƯƠNG BA
Machine Translated by Google

trở thành một liên kết yếu nếu chúng không được triển khai đúng cách và bạn nên tránh chúng khi có thể.

Tóm lại, kiến trúc cho các ứng dụng được lưu trữ trên IaaS gần giống với các ứng dụng web doanh nghiệp có kiến

trúc phân tán n tầng. Trong một doanh nghiệp, các ứng dụng phân tán chạy với nhiều điều khiển tại chỗ để bảo mật máy

chủ và mạng kết nối các máy chủ phân tán. Các điều khiển có thể so sánh không tồn tại theo mặc định trong nền tảng

IaaS và phải được thêm thông qua mạng, quyền truy cập của người dùng hoặc dưới dạng các điều khiển cấp ứng dụng.

Khách hàng của các đám mây IaaS chịu trách nhiệm về tất cả các khía cạnh bảo mật ứng dụng của họ và nên thực hiện các

bước cần thiết để bảo vệ ứng dụng của họ nhằm giải quyết các mối đe dọa cấp ứng dụng trong nhiều bên thuê và thù địch.

môi trường Internet.

Bảng 3-5 liệt kê các biện pháp kiểm soát bảo mật áp dụng cho các ứng dụng IaaS.

BẢNG 3-5. Kiểm soát bảo mật áp dụng cho các ứng dụng IaaS

triển vọng mối đe dọa Cao

kiểm soát phòng ngừa Ứng dụng được phát triển bằng quy trình SDLC nhúng bảo mật, cấu hình ít đặc quyền nhất, vá ứng

dụng kịp thời, xác thực người dùng, kiểm soát truy cập, quản lý tài khoản, trình duyệt

được củng cố bằng các bản vá mới nhất, các biện pháp bảo mật điểm cuối bao gồm chống vi-rút, IPS, IDS dựa trên máy chủ,

tường lửa máy chủ và mạng riêng ảo (VPN) để quản trị

điều khiển thám tử Ghi nhật ký, tương quan sự kiện, quét và giám sát lỗ hổng ứng dụng

Hạn chế bảo mật đám mây công cộng

Khách hàng đánh giá đám mây công cộng nên lưu ý rằng có những hạn chế đối với đám mây công cộng khi hỗ trợ các tính

năng bảo mật tùy chỉnh. Các yêu cầu bảo mật như tường lửa ứng dụng, trình tăng tốc SSL, mật mã hoặc quản lý quyền

bằng thiết bị hỗ trợ PKCS 12 không được hỗ trợ trong đám mây SaaS, PaaS hoặc IaaS công cộng. Trong tương lai, các

nhà cung cấp IaaS và PaaS có thể cung cấp một số tính năng bảo mật tinh vi hơn này, tùy thuộc vào nhu cầu của khách

hàng. Nói chung, bất kỳ biện pháp kiểm soát giảm thiểu nào yêu cầu triển khai thiết bị hoặc thiết bị ngoại vi được

gắn cục bộ trong đám mây IaaS/PaaS công cộng đều không

khả thi vào lúc này.

Bản tóm tắt

Trong chương này, chúng ta đã xem xét bảo mật cấp độ mạng, máy chủ và ứng dụng cũng như các vấn đề xung quanh

từng cấp độ liên quan cụ thể đến điện toán đám mây. Ở cấp độ mạng, mặc dù chắc chắn có những thách thức về bảo mật

với điện toán đám mây, nhưng không có thách thức nào trong số đó là do điện toán đám mây gây ra. Thay vào đó, tất cả

các thách thức bảo mật cấp độ mạng liên quan đến điện toán đám mây đều trở nên trầm trọng hơn do điện toán đám mây—

không phải do điện toán đám mây gây ra một cách cụ thể. Tương tự như vậy, các vấn đề bảo mật ở cấp độ máy chủ, chẳng

hạn như nhu cầu gia tăng đối với bảo mật vành đai máy chủ (trái ngược với bảo mật vành đai thực thể tổ chức) và bảo

mật ảo hóa

CƠ SỞ HẠ TẦNG AN NINH Y 59
Machine Translated by Google

môi trường, đang trở nên trầm trọng hơn bởi điện toán đám mây nhưng không phải do nó gây ra. Và điều

tương tự cũng đúng với cấp độ ứng dụng. Chắc chắn, nhu cầu về vòng đời phát triển phần mềm an toàn ngày

càng tăng do tính chất công khai của các ứng dụng đám mây (công khai) và nhu cầu đảm bảo rằng các API đã

được kiểm tra kỹ lưỡng về bảo mật, nhưng các yêu cầu bảo mật cấp ứng dụng đó lại bị hạn chế. trầm trọng

hơn bởi điện toán đám mây và không phải do nó gây ra.

Do đó, các vấn đề về bảo mật cơ sở hạ tầng và điện toán đám mây là tìm hiểu bên nào cung cấp khía cạnh bảo

mật nào (nghĩa là khách hàng cung cấp chúng hay CSP cung cấp chúng)—nói cách khác, xác định ranh giới tin

cậy.

Việc sử dụng API để kiểm soát cách khai thác cơ sở hạ tầng đám mây có một nhược điểm: không giống như

HTTP, API đám mây chưa được chuẩn hóa, vì vậy mỗi nhà cung cấp đám mây có API cụ thể của riêng mình để

quản lý dịch vụ của mình. Đây là trạng thái điển hình của một ngành ở giai đoạn sơ khai, trong đó mỗi nhà

cung cấp có công nghệ độc quyền của riêng mình có xu hướng khóa khách hàng vào dịch vụ của họ vì các API

độc quyền khiến việc thay đổi nhà cung cấp trở nên khó khăn. Tìm kiếm các nhà cung cấp sử dụng API tiêu

chuẩn bất cứ khi nào có thể (http://www.cloud-standards.org có gợi ý về các tiêu chuẩn mới nổi).

Ngày nay, các API tiêu chuẩn có thể được sử dụng để truy cập vào bộ lưu trữ, ví dụ: WebDAV để lưu trữ

tệp; Các API để triển khai và mở rộng ứng dụng có thể sẽ được chuẩn hóa theo thời gian. Ngoài ra, hãy tìm

các nhà cung cấp đám mây hiểu thị trường của riêng họ và cung cấp, chẳng hạn như các cách để lưu trữ và

triển khai các thư viện hình ảnh VM và các thiết bị được cấu hình sẵn.

60 CHƯƠNG BA