🥇Giám sát bảo mật đám mây

Việc di chuyển dữ liệu và ứng dụng lên đám mây đặt ra một thách thức mới đối với các SOC của công ty, vốn không phải lúc nào cũng sẵn sàng giám sát cơ sở hạ tầng của người khác. Theo Netoskope, một doanh nghiệp trung bình (có vẻ như ở Mỹ) sử dụng 1246 dịch vụ đám mây khác nhau, tăng 22% so với một năm trước. 1246 dịch vụ đám mây!!! 175 trong số đó liên quan đến dịch vụ nhân sự, 170 liên quan đến tiếp thị, 110 liên quan đến lĩnh vực truyền thông và 76 liên quan đến tài chính và CRM. Cisco “chỉ” sử dụng 700 dịch vụ đám mây bên ngoài. Vì vậy, tôi hơi bối rối trước những con số này. Nhưng trong mọi trường hợp, vấn đề không nằm ở họ mà là thực tế là đám mây đang bắt đầu được sử dụng khá tích cực bởi ngày càng nhiều công ty muốn có khả năng giám sát cơ sở hạ tầng đám mây tương tự như trong mạng của chính họ. Và xu hướng này ngày càng gia tăng - theo theo Phòng Kế toán Hoa Kỳ Đến năm 2023, 1200 trung tâm dữ liệu sẽ đóng cửa ở Hoa Kỳ (6250 trung tâm đã đóng cửa). Nhưng việc chuyển đổi sang đám mây không chỉ là “hãy chuyển máy chủ của chúng tôi sang nhà cung cấp bên ngoài”. Kiến trúc CNTT mới, phần mềm mới, quy trình mới, hạn chế mới... Tất cả những điều này mang lại những thay đổi đáng kể cho công việc không chỉ của CNTT mà còn cả bảo mật thông tin. Và nếu các nhà cung cấp đã học cách đối phó bằng cách nào đó với việc đảm bảo tính bảo mật của chính đám mây (may mắn thay, có rất nhiều khuyến nghị), thì với việc giám sát bảo mật thông tin đám mây, đặc biệt là trên nền tảng SaaS, sẽ có những khó khăn đáng kể mà chúng ta sẽ nói đến.

Giả sử công ty của bạn đã chuyển một phần cơ sở hạ tầng sang đám mây... Dừng lại. Không theo cách này. Nếu cơ sở hạ tầng đã được chuyển giao và bây giờ bạn chỉ nghĩ đến việc sẽ giám sát nó như thế nào thì bạn đã thua rồi. Trừ khi đó là Amazon, Google hoặc Microsoft (và sau đó có đặt trước), bạn có thể sẽ không có nhiều khả năng giám sát dữ liệu và ứng dụng của mình. Thật tốt nếu bạn có cơ hội làm việc với nhật ký. Đôi khi dữ liệu sự kiện bảo mật sẽ có sẵn nhưng bạn sẽ không có quyền truy cập vào dữ liệu đó. Ví dụ: Office 365. Nếu bạn có giấy phép E1 rẻ nhất thì các sự kiện bảo mật hoàn toàn không có sẵn cho bạn. Nếu bạn có giấy phép E3, dữ liệu của bạn chỉ được lưu trữ trong 90 ngày và chỉ khi bạn có giấy phép E5, thời hạn của nhật ký sẽ có trong một năm (tuy nhiên, điều này cũng có những sắc thái riêng liên quan đến nhu cầu tách riêng). yêu cầu một số chức năng để làm việc với nhật ký từ bộ phận hỗ trợ của Microsoft). Nhân tiện, giấy phép E3 yếu hơn nhiều về chức năng giám sát so với Exchange của công ty. Để đạt được cấp độ tương tự, bạn cần có giấy phép E5 hoặc giấy phép Tuân thủ nâng cao bổ sung. Giấy phép này có thể yêu cầu thêm tiền chưa được tính vào mô hình tài chính của bạn để chuyển sang cơ sở hạ tầng đám mây. Và đây chỉ là một ví dụ về việc đánh giá thấp các vấn đề liên quan đến giám sát an ninh thông tin đám mây. Trong bài viết này, không giả vờ đầy đủ, tôi muốn thu hút sự chú ý đến một số sắc thái cần được tính đến khi chọn nhà cung cấp đám mây từ quan điểm bảo mật. Và cuối bài viết sẽ đưa ra một danh sách kiểm tra đáng để hoàn thành trước khi xem xét rằng vấn đề giám sát an ninh thông tin đám mây đã được giải quyết.

Có một số vấn đề điển hình dẫn đến sự cố trong môi trường đám mây mà các dịch vụ bảo mật thông tin không có thời gian phản hồi hoặc hoàn toàn không nhìn thấy chúng:

Nhật ký bảo mật không tồn tại. Đây là một tình huống khá phổ biến, đặc biệt là ở những người mới tham gia thị trường giải pháp đám mây. Nhưng bạn không nên từ bỏ chúng ngay lập tức. Các công ty nhỏ, đặc biệt là các công ty trong nước, nhạy cảm hơn với yêu cầu của khách hàng và có thể nhanh chóng triển khai một số chức năng cần thiết bằng cách thay đổi lộ trình đã được phê duyệt cho sản phẩm của họ. Có, đây sẽ không phải là mô-đun tương tự của GuardDuty từ Amazon hoặc mô-đun “Bảo vệ chủ động” từ Bitrix, mà ít nhất là một cái gì đó.
Bảo mật thông tin không biết nhật ký được lưu trữ ở đâu hoặc không có quyền truy cập vào chúng. Ở đây cần phải tiến hành đàm phán với nhà cung cấp dịch vụ đám mây - có lẽ anh ta sẽ cung cấp thông tin đó nếu anh ta coi khách hàng là quan trọng đối với mình. Nhưng nhìn chung, sẽ không tốt lắm khi quyền truy cập vào nhật ký được cung cấp “theo quyết định đặc biệt”.
Điều cũng xảy ra là nhà cung cấp đám mây có nhật ký nhưng họ cung cấp khả năng giám sát và ghi lại sự kiện ở mức độ hạn chế, không đủ để phát hiện tất cả các sự cố. Ví dụ: bạn chỉ có thể nhận được nhật ký thay đổi trên trang web hoặc nhật ký các lần xác thực người dùng chứ không nhận được các sự kiện khác, chẳng hạn như lưu lượng truy cập mạng, điều này sẽ ẩn toàn bộ lớp sự kiện đặc trưng cho các nỗ lực tấn công cơ sở hạ tầng đám mây của bạn.
Có nhật ký, nhưng việc truy cập vào chúng rất khó tự động hóa, điều này buộc chúng phải được theo dõi không liên tục mà theo lịch trình. Và nếu bạn không thể tự động tải xuống nhật ký, thì việc tải xuống nhật ký, chẳng hạn như ở định dạng Excel (như với một số nhà cung cấp giải pháp đám mây trong nước), thậm chí có thể dẫn đến việc dịch vụ bảo mật thông tin của công ty miễn cưỡng sửa đổi chúng.
Không có giám sát nhật ký. Đây có lẽ là nguyên nhân chưa rõ ràng nhất dẫn đến xảy ra sự cố an toàn thông tin trong môi trường đám mây. Có vẻ như có nhật ký và có thể tự động truy cập vào chúng, nhưng không ai làm điều này. Tại sao?

Khái niệm bảo mật đám mây chia sẻ

Việc chuyển đổi sang đám mây luôn là tìm kiếm sự cân bằng giữa mong muốn duy trì quyền kiểm soát cơ sở hạ tầng và chuyển nó sang tay chuyên nghiệp hơn của nhà cung cấp đám mây chuyên bảo trì cơ sở hạ tầng. Và trong lĩnh vực bảo mật đám mây, sự cân bằng này cũng phải được tìm kiếm. Hơn nữa, tùy thuộc vào mô hình cung cấp dịch vụ đám mây được sử dụng (IaaS, PaaS, SaaS), số dư này sẽ luôn khác nhau. Trong mọi trường hợp, chúng ta phải nhớ rằng tất cả các nhà cung cấp đám mây ngày nay đều tuân theo cái gọi là mô hình bảo mật thông tin và trách nhiệm chung. Đám mây chịu trách nhiệm về một số thứ và đối với những thứ khác, khách hàng chịu trách nhiệm đưa dữ liệu, ứng dụng, máy ảo và các tài nguyên khác của mình vào đám mây. Sẽ là liều lĩnh nếu mong đợi rằng bằng cách lên đám mây, chúng ta sẽ chuyển mọi trách nhiệm sang nhà cung cấp. Nhưng cũng không khôn ngoan nếu tự mình xây dựng tất cả bảo mật khi chuyển sang đám mây. Cần có sự cân bằng, điều này sẽ phụ thuộc vào nhiều yếu tố: - chiến lược quản lý rủi ro, mô hình mối đe dọa, cơ chế bảo mật có sẵn cho nhà cung cấp đám mây, luật pháp, v.v.

Ví dụ: việc phân loại dữ liệu được lưu trữ trên đám mây luôn là trách nhiệm của khách hàng. Nhà cung cấp đám mây hoặc nhà cung cấp dịch vụ bên ngoài chỉ có thể trợ giúp anh ta bằng các công cụ giúp đánh dấu dữ liệu trên đám mây, xác định vi phạm, xóa dữ liệu vi phạm pháp luật hoặc che giấu dữ liệu đó bằng phương pháp này hay phương pháp khác. Mặt khác, bảo mật vật lý luôn là trách nhiệm của nhà cung cấp đám mây và không thể chia sẻ với khách hàng. Nhưng mọi thứ giữa dữ liệu và cơ sở hạ tầng vật lý chính xác là chủ đề được thảo luận trong bài viết này. Ví dụ: tính khả dụng của đám mây là trách nhiệm của nhà cung cấp và việc thiết lập các quy tắc tường lửa hoặc kích hoạt mã hóa là trách nhiệm của khách hàng. Trong bài viết này, chúng tôi sẽ cố gắng xem xét các cơ chế giám sát bảo mật thông tin nào được các nhà cung cấp đám mây phổ biến khác nhau ở Nga cung cấp ngày nay, các tính năng sử dụng của chúng là gì và khi nào cần xem xét các giải pháp lớp phủ bên ngoài (ví dụ: Cisco E- mail Security) giúp mở rộng khả năng của đám mây của bạn về mặt an ninh mạng. Trong một số trường hợp, đặc biệt nếu bạn đang theo chiến lược nhiều đám mây, bạn sẽ không có lựa chọn nào khác ngoài việc sử dụng các giải pháp giám sát bảo mật thông tin bên ngoài trong nhiều môi trường đám mây cùng một lúc (ví dụ: Cisco CloudLock hoặc Cisco Stealthwatch Cloud). Chà, trong một số trường hợp, bạn sẽ nhận ra rằng nhà cung cấp đám mây mà bạn đã chọn (hoặc áp đặt cho bạn) hoàn toàn không cung cấp bất kỳ khả năng giám sát bảo mật thông tin nào. Điều này thật khó chịu nhưng cũng không hề nhỏ, vì nó cho phép bạn đánh giá đầy đủ mức độ rủi ro liên quan đến việc làm việc với đám mây này.

Vòng đời giám sát bảo mật đám mây

Để giám sát tính bảo mật của các đám mây bạn sử dụng, bạn chỉ có ba tùy chọn:

dựa vào các công cụ do nhà cung cấp đám mây của bạn cung cấp,
sử dụng các giải pháp từ bên thứ ba sẽ giám sát nền tảng IaaS, PaaS hoặc SaaS mà bạn sử dụng,
xây dựng cơ sở hạ tầng giám sát đám mây của riêng bạn (chỉ dành cho nền tảng IaaS/PaaS).

Hãy xem mỗi tùy chọn này có những tính năng gì. Nhưng trước tiên, chúng ta cần hiểu khuôn khổ chung sẽ được sử dụng khi giám sát nền tảng đám mây. Tôi sẽ nêu bật 6 thành phần chính của quy trình giám sát bảo mật thông tin trên đám mây:

Chuẩn bị cơ sở hạ tầng. Xác định các ứng dụng và cơ sở hạ tầng cần thiết để thu thập các sự kiện quan trọng về bảo mật thông tin vào lưu trữ.
Bộ sưu tập. Ở giai đoạn này, các sự kiện bảo mật được tổng hợp từ nhiều nguồn khác nhau để truyền tải tiếp theo nhằm xử lý, lưu trữ và phân tích.
Sự đối đãi. Ở giai đoạn này, dữ liệu được chuyển đổi và làm phong phú để tạo điều kiện thuận lợi cho việc phân tích tiếp theo.
Kho. Thành phần này chịu trách nhiệm lưu trữ ngắn hạn và dài hạn các dữ liệu thô và đã xử lý được thu thập.
Phân tích. Ở giai đoạn này, bạn có khả năng phát hiện sự cố và phản hồi chúng một cách tự động hoặc thủ công.
Báo cáo. Giai đoạn này giúp hình thành các chỉ số chính cho các bên liên quan (quản lý, kiểm toán viên, nhà cung cấp đám mây, khách hàng, v.v.) giúp chúng tôi đưa ra các quyết định nhất định, chẳng hạn như thay đổi nhà cung cấp hoặc tăng cường bảo mật thông tin.

Hiểu được các thành phần này sẽ cho phép bạn nhanh chóng quyết định trong tương lai những gì bạn có thể nhận từ nhà cung cấp của mình và những gì bạn sẽ phải tự làm hoặc nhờ sự tham gia của các nhà tư vấn bên ngoài.

Dịch vụ đám mây tích hợp

Tôi đã viết ở trên rằng nhiều dịch vụ đám mây ngày nay không cung cấp bất kỳ khả năng giám sát bảo mật thông tin nào. Nhìn chung, họ không quan tâm nhiều đến chủ đề bảo mật thông tin. Ví dụ: một trong những dịch vụ phổ biến của Nga để gửi báo cáo cho các cơ quan chính phủ qua Internet (tôi sẽ không đề cập cụ thể đến tên của nó). Toàn bộ phần về tính bảo mật của dịch vụ này xoay quanh việc sử dụng CIPF được chứng nhận. Phần bảo mật thông tin của một dịch vụ đám mây nội địa khác để quản lý tài liệu điện tử cũng không khác. Nó nói về chứng chỉ khóa công khai, mật mã được chứng nhận, loại bỏ các lỗ hổng web, bảo vệ chống lại các cuộc tấn công DDoS, sử dụng tường lửa, sao lưu và thậm chí cả kiểm tra bảo mật thông tin thường xuyên. Nhưng không có một lời nào về việc giám sát cũng như khả năng truy cập vào các sự kiện bảo mật thông tin mà khách hàng của nhà cung cấp dịch vụ này có thể quan tâm.

Nhìn chung, qua cách nhà cung cấp đám mây mô tả các vấn đề bảo mật thông tin trên trang web và trong tài liệu của họ, bạn có thể hiểu vấn đề này nghiêm trọng đến mức nào. Ví dụ: nếu bạn đọc hướng dẫn sử dụng cho các sản phẩm “My Office”, không có từ nào về bảo mật mà có trong tài liệu dành cho sản phẩm riêng biệt “My Office. KS3”, được thiết kế để bảo vệ chống truy cập trái phép, có một danh sách thông thường các điểm thuộc cấp 17 của FSTEC mà “My Office.KS3” triển khai, nhưng nó không mô tả cách triển khai và quan trọng nhất là cách thực hiện tích hợp các cơ chế này với bảo mật thông tin của công ty. Có lẽ tài liệu như vậy tồn tại, nhưng tôi không tìm thấy nó trong phạm vi công cộng, trên trang web “My Office”. Mặc dù có lẽ tôi không có quyền truy cập vào thông tin bí mật này?..

Đối với Bitrix, tình hình tốt hơn nhiều. Tài liệu này mô tả các định dạng của nhật ký sự kiện và thú vị là nhật ký xâm nhập, chứa các sự kiện liên quan đến các mối đe dọa tiềm ẩn đối với nền tảng đám mây. Từ đó bạn có thể lấy ra IP, tên người dùng hoặc khách, nguồn sự kiện, thời gian, Tác nhân người dùng, loại sự kiện, v.v. Đúng, bạn có thể làm việc với những sự kiện này từ bảng điều khiển của chính đám mây hoặc tải lên dữ liệu ở định dạng MS Excel. Hiện nay rất khó để tự động hóa công việc với nhật ký Bitrix và bạn sẽ phải thực hiện một số công việc theo cách thủ công (tải báo cáo lên và tải nó vào SIEM của bạn). Nhưng nếu chúng ta nhớ rằng cho đến gần đây chưa có cơ hội như vậy thì đây là một tiến bộ lớn. Đồng thời, tôi muốn lưu ý rằng nhiều nhà cung cấp đám mây nước ngoài cung cấp chức năng tương tự “dành cho người mới bắt đầu” - hoặc xem nhật ký bằng mắt qua bảng điều khiển hoặc tải dữ liệu lên chính bạn (tuy nhiên, hầu hết tải dữ liệu lên ở định dạng . định dạng csv, không phải Excel).

Không xem xét tùy chọn không ghi nhật ký, các nhà cung cấp đám mây thường cung cấp cho bạn ba tùy chọn để theo dõi các sự kiện bảo mật - bảng thông tin, tải lên dữ liệu và truy cập API. Cách đầu tiên dường như giải quyết được nhiều vấn đề cho bạn, nhưng điều này không hoàn toàn đúng - nếu bạn có nhiều tạp chí, bạn phải chuyển đổi giữa các màn hình hiển thị chúng, làm mất hình ảnh tổng thể. Ngoài ra, nhà cung cấp đám mây không thể cung cấp cho bạn khả năng liên hệ các sự kiện bảo mật và phân tích chúng theo quan điểm bảo mật (thông thường bạn đang xử lý dữ liệu thô mà bạn cần phải tự hiểu). Có những trường hợp ngoại lệ và chúng ta sẽ nói thêm về chúng. Cuối cùng, bạn nên hỏi nhà cung cấp dịch vụ đám mây của bạn ghi lại những sự kiện nào, ở định dạng nào và chúng tương ứng như thế nào với quy trình giám sát bảo mật thông tin của bạn? Ví dụ: nhận dạng và xác thực người dùng và khách. Bitrix tương tự cho phép bạn, dựa trên những sự kiện này, ghi lại ngày và giờ của sự kiện, tên của người dùng hoặc khách (nếu bạn có mô-đun “Phân tích trang web”), đối tượng được truy cập và các yếu tố khác điển hình cho một trang web . Tuy nhiên, các dịch vụ bảo mật thông tin của công ty có thể cần thông tin về việc liệu người dùng có truy cập vào đám mây từ một thiết bị đáng tin cậy hay không (ví dụ: trong mạng công ty, nhiệm vụ này được thực hiện bởi Cisco ISE). Còn một nhiệm vụ đơn giản như chức năng địa lý IP sẽ giúp xác định xem tài khoản người dùng dịch vụ đám mây có bị đánh cắp hay không thì sao? Và ngay cả khi nhà cung cấp đám mây cung cấp nó cho bạn thì điều này vẫn chưa đủ. Cisco CloudLock tương tự không chỉ phân tích vị trí địa lý mà còn sử dụng máy học cho việc này và phân tích dữ liệu lịch sử của từng người dùng cũng như giám sát các điểm bất thường khác nhau trong các nỗ lực nhận dạng và xác thực. Chỉ MS Azure có chức năng tương tự (nếu bạn có đăng ký phù hợp).

Có một khó khăn khác - vì đối với nhiều nhà cung cấp đám mây, giám sát bảo mật thông tin là một chủ đề mới mà họ mới bắt đầu giải quyết, họ liên tục thay đổi điều gì đó trong giải pháp của mình. Hôm nay họ có một phiên bản API, ngày mai là phiên bản khác, ngày mốt là phiên bản thứ ba. Bạn cũng cần phải chuẩn bị cho việc này. Điều này cũng đúng với chức năng có thể thay đổi và phải được tính đến trong hệ thống giám sát bảo mật thông tin của bạn. Ví dụ: Amazon ban đầu có các dịch vụ giám sát sự kiện đám mây riêng biệt—AWS CloudTrail và AWS CloudWatch. Sau đó, một dịch vụ riêng để giám sát các sự kiện bảo mật thông tin xuất hiện - AWS GuardDuty. Sau một thời gian, Amazon đã ra mắt hệ thống quản lý mới, Amazon Security Hub, bao gồm phân tích dữ liệu nhận được từ GuardDuty, Amazon Inspector, Amazon Macie và một số hệ thống khác. Một ví dụ khác là công cụ tích hợp Azure log với SIEM - AzLog. Nó được nhiều nhà cung cấp SIEM tích cực sử dụng, cho đến năm 2018, Microsoft đã thông báo ngừng phát triển và hỗ trợ, điều này khiến nhiều khách hàng đã sử dụng công cụ này gặp phải vấn đề (chúng ta sẽ nói về cách giải quyết vấn đề này sau).

Do đó, hãy theo dõi cẩn thận tất cả các tính năng giám sát mà nhà cung cấp đám mây cung cấp cho bạn. Hoặc dựa vào các nhà cung cấp giải pháp bên ngoài, những người sẽ đóng vai trò trung gian giữa SOC của bạn và đám mây mà bạn muốn giám sát. Đúng, nó sẽ đắt hơn (mặc dù không phải lúc nào cũng vậy), nhưng bạn sẽ chuyển mọi trách nhiệm lên vai người khác. Hay không phải tất cả?.. Hãy nhớ khái niệm về bảo mật được chia sẻ và hiểu rằng chúng ta không thể thay đổi bất cứ điều gì - chúng ta sẽ phải hiểu một cách độc lập cách các nhà cung cấp đám mây khác nhau cung cấp khả năng giám sát bảo mật thông tin cho dữ liệu, ứng dụng, máy ảo và các tài nguyên khác của bạn được lưu trữ trên đám mây. Và chúng ta sẽ bắt đầu với những gì Amazon cung cấp trong phần này.

Ví dụ: Giám sát bảo mật thông tin trong IaaS dựa trên AWS

Vâng, vâng, tôi hiểu rằng Amazon không phải là ví dụ điển hình nhất vì đây là dịch vụ của Mỹ và nó có thể bị chặn như một phần của cuộc chiến chống chủ nghĩa cực đoan và phổ biến thông tin bị cấm ở Nga. Nhưng trong ấn phẩm này, tôi chỉ muốn chỉ ra các nền tảng đám mây khác nhau như thế nào về khả năng giám sát bảo mật thông tin và những điều bạn nên chú ý khi chuyển các quy trình chính của mình sang đám mây từ quan điểm bảo mật. Chà, nếu một số nhà phát triển giải pháp đám mây người Nga học được điều gì đó hữu ích cho bản thân họ thì điều đó thật tuyệt.

Điều đầu tiên phải nói là Amazon không phải là một pháo đài bất khả xâm phạm. Nhiều sự cố khác nhau thường xuyên xảy ra với khách hàng của anh ấy. Ví dụ: tên, địa chỉ, ngày sinh và số điện thoại của 198 triệu cử tri đã bị đánh cắp từ Deep Root Analytics. Công ty Nice Systems của Israel đã đánh cắp 14 triệu hồ sơ thuê bao của Verizon. Tuy nhiên, các khả năng tích hợp của AWS cho phép bạn phát hiện nhiều sự cố. Ví dụ:

tác động đến cơ sở hạ tầng (DDoS)
thỏa hiệp nút (chèn lệnh)
xâm phạm tài khoản và truy cập trái phép
cấu hình và lỗ hổng không chính xác
giao diện và API không an toàn.

Sự khác biệt này là do, như chúng tôi đã tìm hiểu ở trên, bản thân khách hàng chịu trách nhiệm về bảo mật dữ liệu khách hàng. Và nếu anh ta không thèm bật các cơ chế bảo vệ và không bật các công cụ giám sát, thì anh ta sẽ chỉ biết về vụ việc từ giới truyền thông hoặc từ khách hàng của mình.

Để xác định sự cố, bạn có thể sử dụng nhiều dịch vụ giám sát khác nhau do Amazon phát triển (mặc dù những dịch vụ này thường được bổ sung bằng các công cụ bên ngoài như osquery). Vì vậy, trong AWS, tất cả hành động của người dùng đều được giám sát, bất kể chúng được thực hiện như thế nào - thông qua bảng điều khiển quản lý, dòng lệnh, SDK hoặc các dịch vụ AWS khác. Tất cả hồ sơ về hoạt động của từng tài khoản AWS (bao gồm tên người dùng, hành động, dịch vụ, thông số hoạt động và kết quả) và mức sử dụng API đều có sẵn thông qua AWS CloudTrail. Bạn có thể xem các sự kiện này (chẳng hạn như thông tin đăng nhập vào bảng điều khiển AWS IAM) từ bảng điều khiển CloudTrail, phân tích chúng bằng Amazon Athena hoặc “thuê ngoài” chúng cho các giải pháp bên ngoài như Splunk, AlienVault, v.v. Bản thân nhật ký AWS CloudTrail được đặt trong bộ chứa AWS S3 của bạn.

Hai dịch vụ AWS khác cung cấp một số khả năng giám sát quan trọng khác. Đầu tiên, Amazon CloudWatch là dịch vụ giám sát các tài nguyên và ứng dụng AWS, cùng với nhiều dịch vụ khác, cho phép bạn xác định nhiều điểm bất thường khác nhau trong đám mây của mình. Tất cả các dịch vụ AWS tích hợp, chẳng hạn như Amazon Elastic Computing Cloud (máy chủ), Amazon Relational Database Service (cơ sở dữ liệu), Amazon Elastic MapReduce (phân tích dữ liệu) và 30 dịch vụ khác của Amazon, đều sử dụng Amazon CloudWatch để lưu trữ nhật ký của chúng. Nhà phát triển có thể sử dụng API mở từ Amazon CloudWatch để thêm chức năng giám sát nhật ký vào các ứng dụng và dịch vụ tùy chỉnh, cho phép họ mở rộng phạm vi phân tích sự kiện trong bối cảnh bảo mật.

Thứ hai, dịch vụ VPC Flow Logs cho phép bạn phân tích lưu lượng mạng được gửi hoặc nhận bởi máy chủ AWS của bạn (bên ngoài hoặc nội bộ), cũng như giữa các vi dịch vụ. Khi bất kỳ tài nguyên AWS VPC nào của bạn tương tác với mạng, Nhật ký luồng VPC sẽ ghi lại chi tiết về lưu lượng mạng, bao gồm giao diện mạng nguồn và đích, cũng như địa chỉ IP, cổng, giao thức, số byte và số gói mà bạn cái cưa. Những người có kinh nghiệm về bảo mật mạng cục bộ sẽ nhận ra điều này tương tự như các luồng NetFlow, có thể được tạo bởi các thiết bị chuyển mạch, bộ định tuyến và tường lửa cấp doanh nghiệp. Những nhật ký này rất quan trọng đối với mục đích giám sát bảo mật thông tin vì không giống như các sự kiện về hành động của người dùng và ứng dụng, chúng cũng cho phép bạn không bỏ lỡ các tương tác mạng trong môi trường đám mây riêng ảo AWS.

Tóm lại, ba dịch vụ AWS này—AWS CloudTrail, Amazon CloudWatch và VPC Flow Logs—cùng nhau cung cấp thông tin chi tiết khá mạnh mẽ về việc sử dụng tài khoản, hành vi người dùng, quản lý cơ sở hạ tầng, hoạt động ứng dụng và dịch vụ cũng như hoạt động mạng. Ví dụ: chúng có thể được sử dụng để phát hiện những điểm bất thường sau:

Cố gắng quét trang web, tìm kiếm các cửa hậu, tìm kiếm lỗ hổng thông qua hàng loạt “lỗi 404”.
Các cuộc tấn công tiêm nhiễm (ví dụ: tiêm SQL) thông qua hàng loạt “500 lỗi”.
Các công cụ tấn công được biết đến là sqlmap, nikto, w3af, nmap, v.v. thông qua phân tích trường Tác nhân người dùng.

Amazon Web Services cũng đã phát triển các dịch vụ khác cho mục đích an ninh mạng cho phép bạn giải quyết nhiều vấn đề khác. Ví dụ: AWS có dịch vụ tích hợp để kiểm tra các chính sách và cấu hình - AWS Config. Dịch vụ này cung cấp khả năng kiểm tra liên tục các tài nguyên AWS của bạn và cấu hình của chúng. Hãy lấy một ví dụ đơn giản: Giả sử bạn muốn đảm bảo rằng mật khẩu người dùng bị vô hiệu hóa trên tất cả các máy chủ của bạn và quyền truy cập đó chỉ có thể thực hiện được dựa trên chứng chỉ. AWS Config giúp bạn dễ dàng kiểm tra điều này trên tất cả máy chủ của mình. Có những chính sách khác có thể được áp dụng cho máy chủ đám mây của bạn: “Không máy chủ nào có thể sử dụng cổng 22”, “Chỉ quản trị viên mới có thể thay đổi quy tắc tường lửa” hoặc “Chỉ người dùng Ivashko mới có thể tạo tài khoản người dùng mới và anh ấy chỉ có thể làm điều đó vào các ngày Thứ Ba. " Vào mùa hè năm 2016, dịch vụ AWS Config đã được mở rộng để tự động hóa việc phát hiện các hành vi vi phạm chính sách đã phát triển. Quy tắc cấu hình AWS về cơ bản là các yêu cầu cấu hình liên tục cho các dịch vụ Amazon mà bạn sử dụng, tạo ra các sự kiện nếu các chính sách tương ứng bị vi phạm. Ví dụ: thay vì chạy định kỳ các truy vấn AWS Config để xác minh rằng tất cả các ổ đĩa trên máy chủ ảo đều được mã hóa, bạn có thể sử dụng Quy tắc AWS Config để liên tục kiểm tra các ổ đĩa máy chủ nhằm đảm bảo đáp ứng điều kiện này. Và quan trọng nhất, trong bối cảnh của ấn phẩm này, mọi hành vi vi phạm đều tạo ra các sự kiện mà dịch vụ bảo mật thông tin của bạn có thể phân tích.

AWS cũng có các giải pháp bảo mật thông tin doanh nghiệp truyền thống tương đương, cũng tạo ra các sự kiện bảo mật mà bạn có thể và nên phân tích:

Phát hiện xâm nhập - AWS GuardDuty
Kiểm soát rò rỉ thông tin - AWS Macie
EDR (mặc dù nó nói về các điểm cuối trong đám mây hơi kỳ lạ) - AWS Cloudwatch + giải pháp osquery hoặc GRR nguồn mở
Phân tích luồng mạng - AWS Cloudwatch + AWS VPC Flow
Phân tích DNS - AWS Cloudwatch + AWS Route53
AD - Dịch vụ thư mục AWS
Quản lý tài khoản - AWS IAM
SSO - AWS SSO
phân tích bảo mật - Thanh tra AWS
quản lý cấu hình - AWS Config
WAF - AWS WAF.

Tôi sẽ không mô tả chi tiết tất cả các dịch vụ của Amazon có thể hữu ích trong bối cảnh bảo mật thông tin. Điều chính là phải hiểu rằng tất cả chúng đều có thể tạo ra các sự kiện mà chúng tôi có thể và nên phân tích trong bối cảnh bảo mật thông tin, sử dụng cho mục đích này cả khả năng tích hợp của chính Amazon và các giải pháp bên ngoài, chẳng hạn như SIEM, có thể đưa các sự kiện bảo mật đến trung tâm giám sát của bạn và phân tích chúng ở đó cùng với các sự kiện từ các dịch vụ đám mây khác hoặc từ cơ sở hạ tầng nội bộ, thiết bị ngoại vi hoặc thiết bị di động.

Trong mọi trường hợp, tất cả đều bắt đầu từ nguồn dữ liệu cung cấp cho bạn các sự kiện bảo mật thông tin. Những nguồn này bao gồm, nhưng không giới hạn ở:

CloudTrail - Cách sử dụng API và hành động của người dùng
Cố vấn đáng tin cậy - kiểm tra bảo mật dựa trên các phương pháp hay nhất
Config - kiểm kê và cấu hình tài khoản và cài đặt dịch vụ
Nhật ký luồng VPC - kết nối với giao diện ảo
IAM - dịch vụ nhận dạng và xác thực
Nhật ký truy cập ELB - Cân bằng tải
Thanh tra - lỗ hổng ứng dụng
S3 - lưu trữ tập tin
CloudWatch - Hoạt động ứng dụng
SNS là một dịch vụ thông báo.

Amazon, mặc dù cung cấp nhiều nguồn sự kiện và công cụ như vậy cho thế hệ của họ, nhưng lại rất hạn chế về khả năng phân tích dữ liệu được thu thập trong bối cảnh bảo mật thông tin. Bạn sẽ phải nghiên cứu độc lập các nhật ký có sẵn, tìm kiếm các chỉ số thỏa hiệp liên quan trong đó. Trung tâm bảo mật AWS mà Amazon mới ra mắt gần đây nhằm mục đích giải quyết vấn đề này bằng cách trở thành SIEM đám mây cho AWS. Nhưng cho đến nay, nó mới chỉ ở giai đoạn đầu của hành trình và bị giới hạn cả bởi số lượng nguồn mà nó hoạt động cũng như bởi các hạn chế khác do chính kiến trúc và đăng ký của Amazon thiết lập.

Ví dụ: Giám sát bảo mật thông tin trong IaaS dựa trên Azure

Tôi không muốn tranh luận kéo dài về việc nhà cung cấp dịch vụ đám mây nào trong số ba nhà cung cấp đám mây (Amazon, Microsoft hoặc Google) tốt hơn (đặc biệt vì mỗi nhà cung cấp vẫn có những đặc điểm riêng và phù hợp để giải quyết các vấn đề riêng của mình); Hãy tập trung vào khả năng giám sát an ninh thông tin mà những người chơi này cung cấp. Phải thừa nhận rằng Amazon AWS là một trong những công ty đầu tiên trong phân khúc này và do đó đã tiến xa nhất về chức năng bảo mật thông tin (mặc dù nhiều người thừa nhận rằng chúng khó sử dụng). Nhưng điều này không có nghĩa là chúng tôi sẽ bỏ qua những cơ hội mà Microsoft và Google mang lại cho chúng tôi.

Các sản phẩm của Microsoft luôn được phân biệt bởi tính “mở” của chúng và ở Azure, tình hình cũng tương tự. Ví dụ: nếu AWS và GCP luôn xuất phát từ khái niệm “những gì không được phép đều bị cấm”, thì Azure có cách tiếp cận hoàn toàn ngược lại. Ví dụ: khi tạo một mạng ảo trên đám mây và một máy ảo trong đó, tất cả các cổng và giao thức đều được mở và cho phép theo mặc định. Do đó, bạn sẽ phải tốn thêm một chút công sức cho việc thiết lập ban đầu hệ thống kiểm soát truy cập trên đám mây từ Microsoft. Và điều này cũng đặt ra những yêu cầu nghiêm ngặt hơn đối với bạn về hoạt động giám sát trên đám mây Azure.

AWS có một điểm đặc biệt liên quan đến thực tế là khi bạn giám sát các tài nguyên ảo của mình, nếu chúng nằm ở các khu vực khác nhau, thì bạn sẽ gặp khó khăn trong việc kết hợp tất cả các sự kiện và phân tích thống nhất của chúng, để loại bỏ những gì bạn cần phải sử dụng nhiều thủ thuật khác nhau, chẳng hạn như Tạo mã của riêng bạn cho AWS Lambda để truyền tải sự kiện giữa các khu vực. Azure không gặp phải vấn đề này - cơ chế Nhật ký hoạt động của nó theo dõi mọi hoạt động trên toàn bộ tổ chức mà không bị hạn chế. Điều tương tự cũng áp dụng cho AWS Security Hub, được Amazon phát triển gần đây để hợp nhất nhiều chức năng bảo mật trong một trung tâm bảo mật duy nhất, nhưng chỉ trong khu vực của nó, tuy nhiên, điều này không phù hợp với Nga. Azure có Trung tâm bảo mật riêng, không bị ràng buộc bởi các giới hạn khu vực, cung cấp quyền truy cập vào tất cả các tính năng bảo mật của nền tảng đám mây. Hơn nữa, đối với các nhóm địa phương khác nhau, nó có thể cung cấp bộ khả năng bảo vệ riêng, bao gồm các sự kiện bảo mật do họ quản lý. Trung tâm bảo mật AWS vẫn đang trên đường trở nên tương tự như Trung tâm bảo mật Azure. Nhưng thật đáng để thêm một chút thuốc mỡ - bạn có thể tận dụng Azure rất nhiều thứ đã được mô tả trước đây trong AWS, nhưng điều này chỉ được thực hiện một cách thuận tiện nhất đối với Azure AD, Azure Monitor và Azure Security Center. Tất cả các cơ chế bảo mật Azure khác, bao gồm phân tích sự kiện bảo mật, vẫn chưa được quản lý theo cách thuận tiện nhất. Vấn đề được giải quyết một phần nhờ API, có trong tất cả các dịch vụ Microsoft Azure, nhưng điều này sẽ đòi hỏi bạn phải nỗ lực nhiều hơn để tích hợp đám mây với SOC và sự hiện diện của các chuyên gia có trình độ (trên thực tế, giống như bất kỳ SIEM nào khác hoạt động với API đám mây). Một số SIEM, sẽ được thảo luận sau, đã hỗ trợ Azure và có thể tự động hóa nhiệm vụ giám sát nó, nhưng nó cũng có những khó khăn riêng - không phải tất cả chúng đều có thể thu thập tất cả nhật ký mà Azure có.

Việc thu thập và giám sát sự kiện trong Azure được cung cấp bằng dịch vụ Azure Monitor, đây là công cụ chính để thu thập, lưu trữ và phân tích dữ liệu trong đám mây của Microsoft và các tài nguyên của nó - kho Git, bộ chứa, máy ảo, ứng dụng, v.v. Tất cả dữ liệu do Azure Monitor thu thập được chia thành hai loại - số liệu, được thu thập trong thời gian thực và mô tả các chỉ số hiệu suất chính của đám mây Azure và nhật ký, chứa dữ liệu được sắp xếp thành các bản ghi mô tả các khía cạnh nhất định của hoạt động của tài nguyên và dịch vụ Azure. Ngoài ra, bằng cách sử dụng API Trình thu thập dữ liệu, dịch vụ Azure Monitor có thể thu thập dữ liệu từ bất kỳ nguồn REST nào để xây dựng các kịch bản giám sát của riêng mình.

Dưới đây là một số nguồn sự kiện bảo mật mà Azure cung cấp cho bạn và bạn có thể truy cập thông qua Azure Portal, CLI, PowerShell hoặc REST API (và một số nguồn chỉ thông qua Azure Monitor/Insight API):

Nhật ký hoạt động - nhật ký này trả lời các câu hỏi kinh điển về “ai”, “cái gì” và “khi nào” liên quan đến bất kỳ thao tác ghi nào (PUT, POST, DELETE) trên tài nguyên đám mây. Các sự kiện liên quan đến quyền truy cập đọc (GET) không được đưa vào nhật ký này, giống như một số sự kiện khác.
Nhật ký chẩn đoán - chứa dữ liệu về các hoạt động với một tài nguyên cụ thể có trong đăng ký của bạn.
Báo cáo Azure AD - chứa cả hoạt động của người dùng và hoạt động hệ thống liên quan đến quản lý nhóm và người dùng.
Nhật ký sự kiện Windows và Nhật ký hệ thống Linux - chứa các sự kiện từ các máy ảo được lưu trữ trên đám mây.
Số liệu - chứa dữ liệu đo từ xa về hiệu suất và trạng thái hoạt động của các tài nguyên và dịch vụ đám mây của bạn. Đo mỗi phút và lưu trữ. trong vòng 30 ngày.
Nhật ký luồng nhóm bảo mật mạng - chứa dữ liệu về các sự kiện bảo mật mạng được thu thập bằng dịch vụ Network Watcher và giám sát tài nguyên ở cấp độ mạng.
Nhật ký lưu trữ - chứa các sự kiện liên quan đến quyền truy cập vào cơ sở lưu trữ.

Để giám sát, bạn có thể sử dụng SIEM bên ngoài hoặc Azure Monitor tích hợp và các tiện ích mở rộng của nó. Chúng ta sẽ nói về các hệ thống quản lý sự kiện bảo mật thông tin sau, nhưng bây giờ hãy xem chính Azure cung cấp cho chúng ta những gì để phân tích dữ liệu trong bối cảnh bảo mật. Màn hình chính hiển thị mọi thứ liên quan đến bảo mật trong Azure Monitor là Bảng điều khiển kiểm tra và bảo mật phân tích nhật ký (phiên bản miễn phí hỗ trợ một lượng lưu trữ sự kiện giới hạn chỉ trong một tuần). Bảng thông tin này được chia thành 5 khu vực chính giúp trực quan hóa số liệu thống kê tóm tắt về những gì đang xảy ra trong môi trường đám mây bạn đang sử dụng:

Miền bảo mật - các chỉ số định lượng quan trọng liên quan đến bảo mật thông tin - số lượng sự cố, số lượng nút bị xâm nhập, số lượng nút chưa được vá, sự kiện bảo mật mạng, v.v.
Các vấn đề đáng chú ý - hiển thị số lượng và tầm quan trọng của các vấn đề bảo mật thông tin đang hoạt động
Phát hiện - hiển thị các kiểu tấn công được sử dụng để chống lại bạn
Thông tin về mối đe dọa - hiển thị thông tin địa lý trên các nút bên ngoài đang tấn công bạn
Các truy vấn bảo mật phổ biến - các truy vấn điển hình sẽ giúp bạn giám sát bảo mật thông tin của mình tốt hơn.

Các tiện ích mở rộng Azure Monitor bao gồm Azure Key Vault (bảo vệ khóa mật mã trên đám mây), Đánh giá phần mềm độc hại (phân tích khả năng bảo vệ chống lại mã độc trên máy ảo), Phân tích cổng ứng dụng Azure (phân tích, trong số những thứ khác, nhật ký tường lửa đám mây), v.v. . Những công cụ này, được bổ sung thêm các quy tắc nhất định để xử lý sự kiện, cho phép bạn hình dung các khía cạnh khác nhau của hoạt động của dịch vụ đám mây, bao gồm cả bảo mật và xác định những sai lệch nhất định so với hoạt động. Tuy nhiên, như thường lệ, bất kỳ chức năng bổ sung nào đều yêu cầu đăng ký trả phí tương ứng, điều này sẽ yêu cầu bạn đầu tư tài chính tương ứng mà bạn cần lập kế hoạch trước.

Azure có một số khả năng giám sát mối đe dọa tích hợp sẵn được tích hợp vào Azure AD, Azure Monitor và Azure Security Center. Ví dụ: trong số đó, phát hiện sự tương tác của máy ảo với các IP độc hại đã biết (do tích hợp với các dịch vụ Threat Intelligence của Microsoft), phát hiện phần mềm độc hại trong cơ sở hạ tầng đám mây bằng cách nhận cảnh báo từ các máy ảo được lưu trữ trên đám mây, mật khẩu đoán các cuộc tấn công ” trên máy ảo, lỗ hổng trong cấu hình hệ thống nhận dạng người dùng, đăng nhập vào hệ thống từ trình ẩn danh hoặc nút bị nhiễm, rò rỉ tài khoản, đăng nhập vào hệ thống từ các vị trí bất thường, v.v. Azure ngày nay là một trong số ít nhà cung cấp đám mây cung cấp cho bạn khả năng Thông tin về mối đe dọa tích hợp sẵn để làm phong phú thêm các sự kiện bảo mật thông tin được thu thập.

Như đã đề cập ở trên, chức năng bảo mật và do đó, các sự kiện bảo mật do nó tạo ra không được cung cấp như nhau cho tất cả người dùng mà yêu cầu một gói đăng ký nhất định bao gồm chức năng bạn cần, tạo ra các sự kiện thích hợp để giám sát bảo mật thông tin. Ví dụ: một số chức năng được mô tả trong đoạn trước để theo dõi những điểm bất thường trong tài khoản chỉ có trong giấy phép cao cấp P2 dành cho dịch vụ Azure AD. Nếu không có nó, bạn, như trong trường hợp của AWS, sẽ phải phân tích các sự kiện bảo mật được thu thập một cách “thủ công”. Ngoài ra, tùy thuộc vào loại giấy phép Azure AD, không phải tất cả các sự kiện đều có sẵn để phân tích.

Trên cổng thông tin Azure, bạn có thể quản lý cả truy vấn tìm kiếm nhật ký mà bạn quan tâm và thiết lập bảng thông tin để trực quan hóa các chỉ báo bảo mật thông tin chính. Ngoài ra, ở đó bạn có thể chọn tiện ích mở rộng Azure Monitor, cho phép bạn mở rộng chức năng của nhật ký Azure Monitor và phân tích sâu hơn về các sự kiện từ quan điểm bảo mật.

Nếu bạn không chỉ cần khả năng làm việc với nhật ký mà còn cần một trung tâm bảo mật toàn diện cho nền tảng đám mây Azure của mình, bao gồm quản lý chính sách bảo mật thông tin, thì bạn có thể nói về nhu cầu làm việc với Trung tâm bảo mật Azure, hầu hết các chức năng hữu ích của nó có sẵn với một số tiền, ví dụ: phát hiện mối đe dọa, giám sát bên ngoài Azure, đánh giá tuân thủ, v.v. (trong phiên bản miễn phí, bạn chỉ có quyền truy cập vào đánh giá bảo mật và đề xuất để loại bỏ các vấn đề đã xác định). Nó hợp nhất tất cả các vấn đề bảo mật ở một nơi. Trên thực tế, chúng ta có thể nói về mức độ bảo mật thông tin cao hơn mức Azure Monitor cung cấp cho bạn, vì trong trường hợp này, dữ liệu được thu thập trong toàn bộ nhà máy đám mây của bạn được bổ sung bằng nhiều nguồn, chẳng hạn như Azure, Office 365, Microsoft CRM trực tuyến, Microsoft Dynamics AX , outlook .com, MSN.com, Đơn vị Tội phạm Kỹ thuật số của Microsoft (DCU) và Trung tâm Phản hồi Bảo mật của Microsoft (MSRC), trên đó áp dụng nhiều thuật toán phân tích hành vi và học máy phức tạp khác nhau, cuối cùng sẽ cải thiện hiệu quả của việc phát hiện và ứng phó với các mối đe dọa .

Azure cũng có SIEM riêng - nó xuất hiện vào đầu năm 2019. Đây là Azure Sentinel, dựa trên dữ liệu từ Azure Monitor và cũng có thể tích hợp với. các giải pháp bảo mật bên ngoài (ví dụ: NGFW hoặc WAF), danh sách các giải pháp này không ngừng tăng lên. Ngoài ra, thông qua việc tích hợp API Microsoft Graph Security, bạn có khả năng kết nối nguồn cấp dữ liệu Thông tin về mối đe dọa của riêng mình với Sentinel, giúp nâng cao khả năng phân tích sự cố trong đám mây Azure của bạn. Có thể lập luận rằng Azure Sentinel là SIEM “bản địa” đầu tiên xuất hiện từ các nhà cung cấp đám mây (cùng loại Splunk hoặc ELK, có thể được lưu trữ trên đám mây, chẳng hạn như AWS, vẫn chưa được các nhà cung cấp dịch vụ đám mây truyền thống phát triển). Azure Sentinel và Trung tâm bảo mật có thể được gọi là SOC cho đám mây Azure và có thể bị giới hạn ở chúng (với một số đặt trước nhất định) nếu bạn không còn bất kỳ cơ sở hạ tầng nào nữa và bạn đã chuyển tất cả tài nguyên máy tính của mình sang đám mây và đó sẽ là đám mây Azure của Microsoft.

Nhưng vì các khả năng tích hợp của Azure (ngay cả khi bạn đăng ký Sentinel) thường không đủ cho mục đích giám sát bảo mật thông tin và tích hợp quy trình này với các nguồn sự kiện bảo mật khác (cả đám mây và nội bộ), nên có một cần xuất dữ liệu đã thu thập sang các hệ thống bên ngoài, có thể bao gồm SIEM. Điều này được thực hiện bằng cả API và sử dụng các tiện ích mở rộng đặc biệt, hiện chỉ có sẵn chính thức cho các SIEM sau - Splunk (Azure Monitor Add-On for Splunk), IBM QRadar (Microsoft Azure DSM), SumoLogic, ArcSight và ELK. Cho đến gần đây, đã có nhiều SIEM như vậy hơn, nhưng từ ngày 1 tháng 2019 năm XNUMX, Microsoft đã ngừng hỗ trợ Công cụ tích hợp nhật ký Azure (AzLog), công cụ này vào thời điểm bình minh của sự tồn tại của Azure và do không có tiêu chuẩn hóa thông thường khi làm việc với nhật ký (Azure Màn hình thậm chí còn chưa tồn tại) giúp dễ dàng tích hợp SIEM bên ngoài với đám mây của Microsoft. Giờ đây, tình hình đã thay đổi và Microsoft khuyến nghị nền tảng Azure Event Hub làm công cụ tích hợp chính cho các SIEM khác. Nhiều người đã triển khai tích hợp như vậy, nhưng hãy cẩn thận - họ có thể không ghi lại tất cả nhật ký Azure mà chỉ một số nhật ký (xem tài liệu về SIEM của bạn).

Kết thúc chuyến tham quan ngắn gọn về Azure, tôi muốn đưa ra khuyến nghị chung về dịch vụ đám mây này - trước khi nói bất cứ điều gì về các chức năng giám sát bảo mật thông tin trong Azure, bạn nên định cấu hình chúng thật cẩn thận và kiểm tra xem chúng có hoạt động như được ghi trong tài liệu hay không và như các nhà tư vấn đã nói với bạn Microsoft (và họ có thể có quan điểm khác nhau về chức năng của các chức năng Azure). Nếu có đủ nguồn lực tài chính, bạn có thể khai thác được rất nhiều thông tin hữu ích từ Azure về mặt giám sát bảo mật thông tin. Nếu tài nguyên của bạn bị hạn chế, thì như trong trường hợp của AWS, bạn sẽ chỉ phải dựa vào sức mạnh của chính mình và dữ liệu thô mà Azure Monitor cung cấp cho bạn. Và hãy nhớ rằng nhiều chức năng giám sát sẽ tốn tiền và tốt hơn hết bạn nên tự làm quen với chính sách giá cả trước. Ví dụ: miễn phí, bạn có thể lưu trữ dữ liệu trong 31 ngày với tối đa 5 GB cho mỗi khách hàng - vượt quá các giá trị này sẽ yêu cầu bạn phải trả thêm tiền (khoảng hơn 2 USD để lưu trữ mỗi GB bổ sung từ khách hàng và 0,1 USD cho lưu trữ thêm 1 GB mỗi tháng). Làm việc với phép đo từ xa và số liệu của ứng dụng cũng có thể yêu cầu thêm tiền, cũng như làm việc với các cảnh báo và thông báo (một giới hạn nhất định được cung cấp miễn phí, có thể không đủ cho nhu cầu của bạn).

Ví dụ: Giám sát bảo mật thông tin trong IaaS dựa trên Google Cloud Platform

Google Cloud Platform trông có vẻ trẻ trung hơn so với AWS và Azure, nhưng điều này cũng có phần tốt. Không giống như AWS, công ty ngày càng tăng cường các khả năng của mình, bao gồm cả khả năng bảo mật, gặp vấn đề về tập trung hóa; GCP, giống như Azure, được quản lý tập trung tốt hơn nhiều, giúp giảm lỗi và thời gian triển khai trên toàn doanh nghiệp. Từ quan điểm bảo mật, GCP kỳ lạ thay lại nằm giữa AWS và Azure. Anh ấy cũng có một bản đăng ký sự kiện duy nhất cho toàn bộ tổ chức, nhưng nó chưa đầy đủ. Một số chức năng vẫn đang ở chế độ beta, nhưng dần dần sự thiếu sót này sẽ được loại bỏ và GCP sẽ trở thành một nền tảng trưởng thành hơn về mặt giám sát bảo mật thông tin.

Công cụ chính để ghi nhật ký sự kiện trong GCP là Stackdriver Logging (tương tự Azure Monitor), cho phép bạn thu thập các sự kiện trên toàn bộ cơ sở hạ tầng đám mây của mình (cũng như từ AWS). Từ góc độ bảo mật trong GCP, mỗi tổ chức, dự án hoặc thư mục có bốn nhật ký:

Hoạt động của quản trị viên - chứa tất cả các sự kiện liên quan đến quyền truy cập quản trị, ví dụ: tạo máy ảo, thay đổi quyền truy cập, v.v. Nhật ký này luôn được ghi lại bất kể mong muốn của bạn và lưu trữ dữ liệu trong 400 ngày.
Truy cập dữ liệu - chứa tất cả các sự kiện liên quan đến làm việc với dữ liệu của người dùng đám mây (tạo, sửa đổi, đọc, v.v.). Theo mặc định, nhật ký này không được ghi vì âm lượng của nó tăng lên rất nhanh. Vì lý do này, thời hạn sử dụng của nó chỉ là 30 ngày. Ngoài ra, không phải tất cả mọi thứ đều được viết trong tạp chí này. Ví dụ: các sự kiện liên quan đến tài nguyên có thể truy cập công khai đối với tất cả người dùng hoặc có thể truy cập mà không cần đăng nhập vào GCP sẽ không được ghi vào đó.
Sự kiện hệ thống - chứa các sự kiện hệ thống không liên quan đến người dùng hoặc hành động của quản trị viên thay đổi cấu hình tài nguyên đám mây. Nó luôn được viết và lưu trữ trong 400 ngày.
Tính minh bạch của quyền truy cập là một ví dụ độc đáo về nhật ký ghi lại mọi hành động của nhân viên Google (nhưng chưa phải đối với tất cả các dịch vụ GCP), những người truy cập vào cơ sở hạ tầng của bạn như một phần nhiệm vụ công việc của họ. Nhật ký này được lưu trữ trong 400 ngày và không phải mọi khách hàng GCP đều có sẵn mà chỉ khi một số điều kiện được đáp ứng (hỗ trợ ở cấp độ Vàng hoặc Bạch kim hoặc sự hiện diện của 4 vai trò thuộc một loại nhất định như một phần hỗ trợ của công ty). Một chức năng tương tự cũng có sẵn, chẳng hạn như trong Office 365 - Lockbox.

Ví dụ về nhật ký: Tính minh bạch của quyền truy cập

{
 insertId:  "abcdefg12345"
 jsonPayload: {
  @type:  "type.googleapis.com/google.cloud.audit.TransparencyLog"
  location: {
   principalOfficeCountry:  "US"
   principalEmployingEntity:  "Google LLC"
   principalPhysicalLocationCountry:  "CA"
  }
  product: [
   0:  "Cloud Storage"
  ]
  reason: [
    detail:  "Case number: bar123"
    type:  "CUSTOMER_INITIATED_SUPPORT"
  ]
  accesses: [
   0: {
    methodName: "GoogleInternal.Read"
    resourceName: "//googleapis.com/storage/buckets/[BUCKET_NAME]/objects/foo123"
    }
  ]
 }
 logName:  "projects/[PROJECT_NAME]/logs/cloudaudit.googleapis.com%2Faccess_transparency"
 operation: {
  id:  "12345xyz"
 }
 receiveTimestamp:  "2017-12-18T16:06:37.400577736Z"
 resource: {
  labels: {
   project_id:  "1234567890"
  }
  type:  "project"
 }
 severity:  "NOTICE"
 timestamp:  "2017-12-18T16:06:24.660001Z"
}

Bạn có thể truy cập vào các nhật ký này theo nhiều cách (giống như cách đã thảo luận trước đây về Azure và AWS) - thông qua giao diện Trình xem nhật ký, thông qua API, thông qua Google Cloud SDK hoặc thông qua trang Hoạt động của dự án mà bạn tham gia quan tâm đến các sự kiện. Theo cách tương tự, chúng có thể được xuất sang các giải pháp bên ngoài để phân tích bổ sung. Việc sau được thực hiện bằng cách xuất nhật ký sang bộ lưu trữ BigQuery hoặc Cloud Pub/Sub.

Ngoài Ghi nhật ký Stackdriver, nền tảng GCP còn cung cấp chức năng Giám sát Stackdriver, cho phép bạn giám sát các số liệu chính (hiệu suất, MTBF, tình trạng tổng thể, v.v.) của các ứng dụng và dịch vụ đám mây. Dữ liệu được xử lý và trực quan hóa có thể giúp bạn dễ dàng tìm thấy các sự cố trong cơ sở hạ tầng đám mây của mình, kể cả trong bối cảnh bảo mật. Nhưng cần lưu ý rằng chức năng này sẽ không phong phú lắm trong bối cảnh bảo mật thông tin, vì GCP ngày nay không có chức năng tương tự như AWS GuardDuty và không thể xác định những sự kiện xấu trong số tất cả các sự kiện đã đăng ký (Google đã phát triển Phát hiện mối đe dọa sự kiện, nhưng nó vẫn đang được phát triển ở giai đoạn thử nghiệm và còn quá sớm để nói về tính hữu dụng của nó). Giám sát Stackdriver có thể được sử dụng như một hệ thống để phát hiện các điểm bất thường, sau đó sẽ được điều tra để tìm ra nguyên nhân xuất hiện của chúng. Nhưng do thị trường thiếu nhân sự có trình độ chuyên môn trong lĩnh vực bảo mật thông tin GCP nên nhiệm vụ này hiện có vẻ khó khăn.

Bạn cũng nên đưa ra danh sách một số mô-đun bảo mật thông tin có thể được sử dụng trong đám mây GCP của mình và tương tự như những gì AWS cung cấp:

Trung tâm chỉ huy bảo mật đám mây tương tự như Trung tâm bảo mật AWS và Trung tâm bảo mật Azure.
Cloud DLP - Tự động phát hiện và chỉnh sửa (ví dụ: che giấu) dữ liệu được lưu trữ trên đám mây bằng cách sử dụng hơn 90 chính sách phân loại được xác định trước.
Cloud Scanner là công cụ quét các lỗ hổng đã biết (XSS, Flash Tiêm, các thư viện chưa được vá, v.v.) trong App Engine, Computing Engine và Google Kubernetes.
Cloud IAM - Kiểm soát quyền truy cập vào tất cả tài nguyên GCP.
Cloud Identity - Quản lý tài khoản người dùng, thiết bị và ứng dụng GCP từ một bảng điều khiển duy nhất.
Cloud HSM - bảo vệ khóa mật mã.
Dịch vụ quản lý khóa đám mây - quản lý khóa mật mã trong GCP.
Kiểm soát dịch vụ VPC - Tạo vành đai an toàn xung quanh tài nguyên GCP của bạn để bảo vệ chúng khỏi bị rò rỉ.
Khóa bảo mật Titan - bảo vệ chống lừa đảo.

Nhiều mô-đun trong số này tạo ra các sự kiện bảo mật có thể được gửi tới bộ lưu trữ BigQuery để phân tích hoặc xuất sang các hệ thống khác, bao gồm SIEM. Như đã đề cập ở trên, GCP là một nền tảng đang phát triển tích cực và Google hiện đang phát triển một số mô-đun bảo mật thông tin mới cho nền tảng của mình. Trong số đó có tính năng Phát hiện mối đe dọa sự kiện (hiện có sẵn ở phiên bản beta), quét nhật ký Stackdriver để tìm kiếm dấu vết của hoạt động trái phép (tương tự như GuardDuty trong AWS) hoặc Thông tin chính sách (có sẵn ở phiên bản alpha), cho phép bạn phát triển các chính sách thông minh cho truy cập vào tài nguyên GCP.

Tôi đã trình bày tổng quan ngắn gọn về khả năng giám sát tích hợp trong các nền tảng đám mây phổ biến. Nhưng bạn có chuyên gia nào có thể làm việc với nhật ký của nhà cung cấp IaaS “thô” không (không phải ai cũng sẵn sàng mua các khả năng nâng cao của AWS, Azure hoặc Google)? Ngoài ra, nhiều người đã quen thuộc với câu ngạn ngữ “tin cậy nhưng hãy xác minh”, câu nói này đúng hơn bao giờ hết trong lĩnh vực bảo mật. Bạn tin tưởng đến mức nào khả năng tích hợp của nhà cung cấp đám mây gửi cho bạn các sự kiện bảo mật thông tin? Họ tập trung vào bảo mật thông tin đến mức nào?

Đôi khi, bạn nên xem xét các giải pháp giám sát cơ sở hạ tầng đám mây lớp phủ có thể bổ sung cho bảo mật đám mây tích hợp và đôi khi các giải pháp đó là lựa chọn duy nhất để hiểu rõ hơn về tính bảo mật của dữ liệu và ứng dụng được lưu trữ trên đám mây của bạn. Ngoài ra, chúng còn tiện lợi hơn vì chúng đảm nhận tất cả nhiệm vụ phân tích nhật ký cần thiết được tạo bởi các dịch vụ đám mây khác nhau từ các nhà cung cấp đám mây khác nhau. Một ví dụ về giải pháp lớp phủ như vậy là Cisco Stealthwatch Cloud, tập trung vào một nhiệm vụ duy nhất - giám sát các điểm bất thường về bảo mật thông tin trong môi trường đám mây, không chỉ bao gồm Amazon AWS, Microsoft Azure và Google Cloud Platform mà còn cả các đám mây riêng.

Ví dụ: Giám sát bảo mật thông tin bằng Stealthwatch Cloud

AWS cung cấp nền tảng điện toán linh hoạt, nhưng tính linh hoạt này khiến các công ty dễ mắc sai lầm dẫn đến các vấn đề về bảo mật. Và mô hình bảo mật thông tin chia sẻ chỉ góp phần vào việc này. Chạy phần mềm trên đám mây có lỗ hổng không xác định (ví dụ: những lỗ hổng đã biết có thể được chống lại bởi AWS Inspector hoặc GCP Cloud Scanner), mật khẩu yếu, cấu hình không chính xác, nội bộ, v.v. Và tất cả điều này được phản ánh trong hành vi của tài nguyên đám mây, có thể được giám sát bởi Cisco Stealthwatch Cloud, một hệ thống giám sát an ninh thông tin và phát hiện tấn công. đám mây công cộng và riêng tư.

Một trong những tính năng chính của Cisco Stealthwatch Cloud là khả năng lập mô hình các thực thể. Với nó, bạn có thể tạo mô hình phần mềm (nghĩa là mô phỏng gần như thời gian thực) cho từng tài nguyên đám mây của mình (không quan trọng đó là AWS, Azure, GCP hay thứ gì khác). Chúng có thể bao gồm máy chủ và người dùng cũng như các loại tài nguyên dành riêng cho môi trường đám mây của bạn, chẳng hạn như nhóm bảo mật và nhóm tự động mở rộng quy mô. Các mô hình này sử dụng luồng dữ liệu có cấu trúc do dịch vụ đám mây cung cấp làm đầu vào. Ví dụ: đối với AWS, đây sẽ là VPC Flow Logs, AWS CloudTrail, AWS CloudWatch, AWS Config, AWS Inspector, AWS Lambda và AWS IAM. Lập mô hình thực thể tự động phát hiện vai trò và hành vi của bất kỳ tài nguyên nào của bạn (bạn có thể nói về việc lập hồ sơ tất cả hoạt động trên đám mây). Những vai trò này bao gồm thiết bị di động Android hoặc Apple, máy chủ Citrix PVS, máy chủ RDP, cổng thư, máy khách VoIP, máy chủ đầu cuối, bộ điều khiển miền, v.v. Sau đó, nó liên tục theo dõi hành vi của họ để xác định khi nào hành vi nguy hiểm hoặc đe dọa đến an toàn xảy ra. Bạn có thể xác định việc đoán mật khẩu, tấn công DDoS, rò rỉ dữ liệu, truy cập từ xa bất hợp pháp, hoạt động mã độc, quét lỗ hổng và các mối đe dọa khác. Ví dụ: đây là quá trình phát hiện nỗ lực truy cập từ xa từ một quốc gia không điển hình cho tổ chức của bạn (Hàn Quốc) đến cụm Kubernetes thông qua SSH trông như sau:

Và đây là những gì được cho là rò rỉ thông tin từ cơ sở dữ liệu của Postgress đến một quốc gia mà trước đây chúng tôi chưa từng gặp phải sự tương tác:

Cuối cùng, đây là tình trạng mà quá nhiều lần thử SSH thất bại từ Trung Quốc và Indonesia từ một thiết bị từ xa bên ngoài trông như sau:

Hoặc, giả sử rằng phiên bản máy chủ trong VPC, theo chính sách, không bao giờ là đích đăng nhập từ xa. Giả sử thêm rằng máy tính này đã đăng nhập từ xa do có sự thay đổi sai lầm trong chính sách quy tắc tường lửa. Tính năng Lập mô hình thực thể sẽ phát hiện và báo cáo hoạt động này (“Truy cập từ xa bất thường”) trong thời gian gần như thời gian thực và trỏ đến lệnh gọi API ghi nhật ký AWS CloudTrail, Azure Monitor hoặc GCP Stackdriver cụ thể (bao gồm tên người dùng, ngày và giờ, cùng các chi tiết khác ), điều này đã thúc đẩy sự thay đổi quy tắc của ITU. Và sau đó thông tin này có thể được gửi đến SIEM để phân tích.

Các khả năng tương tự được triển khai cho mọi môi trường đám mây được Cisco Stealthwatch Cloud hỗ trợ:

Mô hình hóa thực thể là một hình thức tự động hóa bảo mật độc đáo có thể phát hiện ra một vấn đề chưa từng được biết đến với con người, quy trình hoặc công nghệ của bạn. Ví dụ: nó cho phép bạn phát hiện các vấn đề bảo mật như:

Có ai đó phát hiện ra cửa hậu trong phần mềm chúng ta sử dụng không?
Có phần mềm hoặc thiết bị của bên thứ ba nào trên đám mây của chúng tôi không?
Người dùng được ủy quyền có lạm dụng đặc quyền không?
Có lỗi cấu hình nào cho phép truy cập từ xa hoặc sử dụng tài nguyên ngoài ý muốn không?
Có rò rỉ dữ liệu từ máy chủ của chúng tôi không?
Có phải ai đó đang cố gắng kết nối với chúng tôi từ một vị trí địa lý không điển hình không?
Đám mây của chúng tôi có bị nhiễm mã độc không?

Một sự kiện bảo mật thông tin được phát hiện có thể được gửi dưới dạng một phiếu tương ứng tới Slack, Cisco Spark, hệ thống quản lý sự cố PagerDuty, đồng thời được gửi đến nhiều SIEM khác nhau, bao gồm Splunk hoặc ELK. Tóm lại, chúng tôi có thể nói rằng nếu công ty của bạn sử dụng chiến lược nhiều đám mây và không giới hạn ở bất kỳ nhà cung cấp đám mây nào, khả năng giám sát bảo mật thông tin được mô tả ở trên thì sử dụng Cisco Stealthwatch Cloud là một lựa chọn tốt để có được một bộ giám sát thống nhất khả năng dành cho những công ty cung cấp dịch vụ đám mây hàng đầu - Amazon , Microsoft và Google. Điều thú vị nhất là nếu bạn so sánh giá của Stealthwatch Cloud với các giấy phép nâng cao về giám sát bảo mật thông tin trong AWS, Azure hoặc GCP, thì có thể giải pháp của Cisco sẽ còn rẻ hơn cả khả năng tích hợp sẵn của Amazon, Microsoft và các giải pháp của Google. Thật là nghịch lý, nhưng đó là sự thật. Và bạn càng sử dụng nhiều đám mây và khả năng của chúng thì lợi thế của giải pháp hợp nhất sẽ càng rõ ràng.

Ngoài ra, Stealthwatch Cloud có thể giám sát các đám mây riêng được triển khai trong tổ chức của bạn, chẳng hạn như dựa trên các vùng chứa Kubernetes hoặc bằng cách giám sát các luồng Netflow hoặc lưu lượng mạng nhận được thông qua phản chiếu trong thiết bị mạng (thậm chí được sản xuất trong nước), dữ liệu AD hoặc máy chủ DNS, v.v. Tất cả dữ liệu này sẽ được bổ sung thêm thông tin Thông tin về mối đe dọa do Cisco Talos, nhóm nghiên cứu mối đe dọa an ninh mạng phi chính phủ lớn nhất thế giới thu thập.

Điều này cho phép bạn triển khai hệ thống giám sát thống nhất cho cả đám mây công cộng và đám mây lai mà công ty bạn có thể sử dụng. Sau đó, thông tin được thu thập có thể được phân tích bằng các khả năng tích hợp của Stealthwatch Cloud hoặc gửi đến SIEM của bạn (Splunk, ELK, SumoLogic và một số thông tin khác được hỗ trợ theo mặc định).

Với điều này, chúng ta sẽ hoàn thành phần đầu tiên của bài viết, trong đó tôi đã xem xét các công cụ tích hợp và bên ngoài để giám sát bảo mật thông tin của nền tảng IaaS/PaaS, cho phép chúng ta nhanh chóng phát hiện và ứng phó với các sự cố xảy ra trong môi trường đám mây. doanh nghiệp của chúng tôi đã lựa chọn. Trong phần thứ hai, chúng ta sẽ tiếp tục chủ đề và xem xét các tùy chọn giám sát nền tảng SaaS bằng ví dụ về Salesforce và Dropbox, đồng thời chúng ta cũng sẽ cố gắng tóm tắt và kết hợp mọi thứ lại với nhau bằng cách tạo một hệ thống giám sát bảo mật thông tin thống nhất cho các nhà cung cấp đám mây khác nhau.

Nguồn: www.habr.com