Giải thích về cách mở rộng bảo mật API từ mô hình phòng thủ chuyên sâu sang mô hình không tin cậy

“Đại dịch đã đặt ra yêu cầu cấp bách lớn đối với các doanh nghiệp là phải đưa tất cả các loại dự án chuyển đổi kỹ thuật số vào hoạt động càng nhanh càng tốt và đó gần như chắc chắn là một yếu tố thúc đẩy các cuộc tấn công gia tăng này,”

— Peter Klimek , Giám đốc Công nghệ tại Imperva .

API DYKT đã được sử dụng trong hơn 20 năm. Kể từ đó, API đã phát triển mạnh mẽ — từ một nhóm hạn chế các công ty sử dụng API để giải quyết các nhu cầu cụ thể, gần đây là một bộ sưu tập vô tận các trường hợp sử dụng trong môi trường DevOps thuộc mọi quy mô. Bạn có thể tìm thấy các API trong Phát triển ứng dụng — phát triển linh hoạt, kết nối khách hàng và đối tác với các dịch vụ, đồng thời hỗ trợ các sáng kiến chuyển đổi kỹ thuật số.

Nhưng liên quan đến an ninh mạng, theo nghiên cứu của ProgrammableWeb , trung bình có 220 API mới được thêm vào mỗi tháng kể từ năm 2019 . Tuy nhiên, với việc áp dụng rộng rãi hơn, ngày nay các API tiết lộ nhiều dữ liệu nhạy cảm hơn bao giờ hết, khiến chúng trở thành mục tiêu có giá trị cho các cuộc tấn công.

Bài đăng này là phần giới thiệu về cách ánh xạ các yêu cầu của API Security, từ Defense-in-Depth đến Zero Trust Model.

Bối cảnh -Trạng thái bảo mật API

Trước khi tìm hiểu cách bảo mật API, hãy xem bối cảnh mối đe dọa hiện tại của Bảo mật API. Theo Báo cáo trạng thái bảo mật API của Salt Security:

• Các cuộc tấn công API đã tăng 681% trong 12 tháng qua
• 95% số người được hỏi đã gặp sự cố bảo mật API trong năm qua
• 34% số người được hỏi thiếu bất kỳ chiến lược bảo mật API nào
• 62% người trả lời khảo sát thừa nhận làm chậm quá trình triển khai ứng dụng mới vì lo ngại về bảo mật API

Nói tóm lại, chúng ta có thể nói rằng hầu hết các doanh nghiệp đều không chuẩn bị cho một cuộc tấn công dựa trên API. Ngoài ra, việc phụ thuộc vào các công cụ quản lý API và bảo mật hiện có, chẳng hạn như tường lửa ứng dụng web (WAF) và cổng API, có thể đã ngăn chặn hiệu quả các sự cố bảo mật và mang lại cảm giác bảo mật sai lầm.

Điều gì về Shift-Left?

Báo cáo nhấn mạnh rằng các chiến thuật dịch chuyển sang trái không giúp ích gì, ít nhất là về bảo mật API. Hơn 50% số người được hỏi cho biết các nhà phát triển, nhóm DevOps hoặc DevSecOps chịu trách nhiệm về bảo mật API. Các công ty chi tiêu nhiều hơn cho các nỗ lực trước khi triển khai bao gồm:

• mã hóa an toàn thực hành tốt nhất,
• quét mã và
• kiểm tra thủ công

Tuy nhiên, 85% thừa nhận rằng các công cụ bảo mật của họ không hiệu quả trong việc ngăn chặn tấn công API - Chứng tỏ rằng các biện pháp bảo mật DevOps này, mặc dù quan trọng, nhưng là không đủ.

Vì vậy, tổ chức nên xây dựng hoặc áp dụng biện pháp bảo vệ nào để chống lại các cuộc tấn công API? Để trả lời câu hỏi này, trước tiên, chúng ta cần hiểu các cuộc tấn công phổ biến nhằm vào API.

Bối cảnh mối đe dọa hiện tại

Trong báo cáo gần đây về bảo mật API của Google Cloud , các nguồn đe dọa bảo mật API là:

1. API bị định cấu hình sai (40%),
2. API, dữ liệu và thành phần lỗi thời (35%),
3. Thư rác, Lạm dụng, Bot (34%).

Theo một nghiên cứu khác của Imperva Research Labs , cuộc tấn công quan trọng nhất làm tăng Thực thi mã từ xa (RCE) hoặc Bao gồm tệp từ xa (RFI) tăng 271%. Tin tặc sử dụng các cuộc tấn công RCE hoặc RFI để đánh cắp thông tin công ty, xâm phạm máy chủ và thay đổi trang web hoặc thậm chí kiểm soát các trang web.

Các lỗ hổng API khác, theo top 10 của OWASP API Security:

• API DDOS fan-out,
• các cuộc tấn công API zero-day,
• thông tin đăng nhập bị đánh cắp,
• vi phạm vành đai,
• chuyển động bên của các vi phạm,
• rò rỉ dữ liệu ở đầu ra, hoặc
• chiếm đoạt tài nguyên

An ninh mạng: API là Điểm cuối mới

Như đã đề cập ở trên, lý do đầu tiên khiến rủi ro bảo mật của API gia tăng là sự bùng nổ của việc áp dụng - nhiều API trong một môi trường. Ví dụ: một ứng dụng Kubernetes có hàng trăm nhóm và dịch vụ siêu nhỏ. Mỗi người trong số họ đang quản lý nửa tá API trở lên. (Đó là một tình huống điển hình trong môi trường DevOps).

Bây giờ hãy nói thêm rằng các khối lượng công việc vi dịch vụ này (và do đó, các lệnh gọi API) là tạm thời, chạy trên các đám mây, được viết theo kiểu đa ngôn ngữ và sử dụng các giao thức khác nhau. Hay nói tóm lại, API tạo ra một môi trường phức tạp và thách thức đối với nhóm bảo mật trong việc giám sát hoạt động của API.

Thứ hai, các API không bao giờ được dùng để tiếp xúc với thế giới bên ngoài. Tuy nhiên, đây là những gì chúng tôi phải đối mặt với các lỗ hổng được tìm thấy bên trong ngăn xếp giao thức mạng. Những nhà phát triển đó sẽ không bao giờ tưởng tượng được các tác phẩm của họ sẽ được áp dụng trên quy mô ngày nay. Do đó, các API có các lỗ hổng và rủi ro bẩm sinh được tích hợp bên trong chúng.

Thứ ba, các cuộc tấn công và vi phạm ngày càng trở nên tinh vi, đặc biệt là những cuộc tấn công được thực hiện trong giai đoạn hậu xác thực và ủy quyền. Chúng cũng sâu sắc hơn trong tải trọng dữ liệu API.

Do đó, cần phải xem xét bảo mật ngoài xác thực và ủy quyền, cũng như lớp tải trọng dữ liệu API và ứng dụng. Một cách để làm điều đó là coi Bảo mật API tương tự như bảo mật Điểm cuối truyền thống của chúng tôi.

DiD (Phòng thủ chuyên sâu), Một lần nữa!

Các vấn đề về bảo mật cũng xảy ra trong cuộc sống hàng ngày của chúng ta bên ngoài máy tính. Ngay từ giai đoạn đầu của lịch sử nhân loại, nhiều quốc gia đã khám phá và thực hành nhiều cơ chế và công sự phòng thủ. Những kinh nghiệm và ý tưởng này cũng áp dụng cho bảo mật điểm cuối, mạng và API.

Giả sử Phần mềm điểm cuối tương tự như lâu đài:

• Xác thực danh tính bằng bằng chứng ID của người chỉ huy và
• Honeypots (hoặc mồi nhử trong chiến tranh) thu hút những kẻ tấn công khỏi các mục tiêu cao cấp.
• Trong số các chiến lược chiến tranh này, một trong những cách hiệu quả nhất là Defense-in-Depth (DiD).

Cách tiếp cận DiD có thể được chia thành hai lĩnh vực:

1. Boundary Defense (Chữ ký chống phần mềm độc hại)
2. Phát hiện/Ngăn chặn xâm nhập (IDS/IPS/EDR)

Tôi sẽ giải thích lần lượt về bảo mật API với các khu vực DiD này.

1# Phòng thủ ranh giới

Phòng thủ biên giới là loại phòng thủ cơ bản nhất. Hầu như tất cả các công ty đều đầu tư vào việc bảo vệ ranh giới. Trong bảo mật điểm cuối, chúng tôi sử dụng chữ ký và danh sách từ chối IP để chống lại các phương thức tấn công đã biết.

Là tuyến bảo vệ phía trước, lớp này nhằm mục đích ngăn chặn 90% tất cả các cuộc tấn công, không nhắm mục tiêu và được khởi xướng bởi những cá nhân không có kỹ năng, những người không có bí quyết kỹ thuật vững chắc hoặc tư duy của hacker. Trong kịch bản này, phòng thủ ranh giới có thể chống lại các cuộc tấn công bừa bãi này đủ tốt.

Trong Bảo mật API, WAF đang làm rất tốt trong lĩnh vực này. Nó cung cấp các tính năng tiêu chuẩn để bảo vệ ranh giới:

· Danh sách cho phép IP và danh sách từ chối,

· Công cụ quy tắc WAF,

· Tỷ lệ giới hạn, và

· tiêm lỗi/làm mờ.

Khi kết hợp, nó có thể chặn gần như tất cả các cuộc tấn công hàng hóa.

2# Phát hiện xâm nhập (++)

Khả năng hiển thị bảo mật là một yếu tố quan trọng của phòng chống tấn công. Sau khi tin tặc xâm phạm vành đai, chúng ta cần một cách thích hợp để xác định tệp/quy trình/lưu lượng truy cập nào có khả năng liên quan đến cuộc tấn công độc hại. Trong Phần mềm điểm cuối, chúng tôi có IDS/IPS dựa trên máy chủ để kiểm tra tất cả các yêu cầu đi qua cổng trước.

Một số phương pháp phát hiện khác, chẳng hạn như phát hiện APT và học máy, có thể trực quan hơn để đánh giá các cuộc tấn công có chủ đích.

Các cách điển hình khác để thực hiện phân tích hành vi là:

· Honeypots,

· EDR (Phát hiện và phản hồi điểm cuối) và

· Trí thông minh về mối đe dọa (tệp & quy trình).

Trong số tất cả các phương pháp đó, honeypots là một trong những phương pháp lâu đời nhất (kể từ khi bắt đầu chiến tranh). Bằng cách dụ một số mục tiêu có giá trị cao vào bẫy/ mồi nhử, họ có thể phân tích hành vi của kẻ thù và thậm chí giúp xác định vị trí của chúng. Ngày nay, chúng ta áp dụng những chiến thuật này và biến chúng thành công nghệ đánh lừa.

Trong thế giới hiện đại, các giải pháp bảo mật API cung cấp sự kết hợp của các kỹ thuật đã đề cập; ví dụ: các thành phần lạ được thu thập trong honeypots sau đó có thể gửi vào nguồn cấp thông tin tình báo về mối đe dọa để sử dụng WAF hoặc Ứng dụng Web và Bảo vệ API (WAAP). Trong lớp này, chúng tôi có các kỹ thuật tương tự để tăng cường khả năng hiển thị và tốc độ ngăn chặn một cuộc tấn công:

· Mạng Honeypots

· NDR (Phát hiện và phản hồi mạng) và

· Trí thông minh về mối đe dọa (tải trọng & mạng).

Sử dụng bot để thực hiện các cuộc tấn công "nhồi thông tin xác thực" là một chiến thuật tấn công phổ biến khác. Nó cố gắng ăn cắp tài sản có giá trị cao. Chiến lược là tìm cách lấy thông tin đăng nhập, chẳng hạn như email/mật khẩu bị rò rỉ, sau đó cố gắng truy cập các vị trí mạng theo đợt (chuyển động ngang). Cho đến nay, biện pháp bảo vệ hiệu quả nhất để chống lại việc nhồi thông tin xác thực là từ nguồn: xác định bot từ người dùng thực để chặn tất cả các yêu cầu do bot đưa ra.

Do đó, một số công cụ AppSec cũng trang bị các tính năng chống bot, một loại phát hiện hành vi cụ thể như một phần của bảo mật API.

Khi bảo mật API đáp ứng Zero Trust

Tôi không nói DiD là vô dụng. Các giải pháp API và Bảo mật ứng dụng như bảo vệ WAF cho các tổ chức khỏi các cuộc tấn công hàng hóa. Tuy nhiên, như đã đề cập, API tạo ra một môi trường phức tạp và việc cấu hình sai sẽ làm vấn đề trở nên trầm trọng hơn.

Với một chu vi không rõ ràng, có thể cần nhiều hơn cách tiếp cận DiD. Zero Trust về cơ bản đặt chướng ngại vật ở khắp mọi nơi cho những kẻ tấn công, khiến chúng không thể di chuyển ngang trong môi trường.

Zero Trust là một khuôn khổ và chiến lược bảo mật toàn diện. Nó yêu cầu các bước xác minh nghiêm ngặt và thống nhất cho tất cả các thiết bị đầu cuối, BYOD (Mang theo thiết bị của riêng bạn), máy chủ, API, vi dịch vụ, bộ lưu trữ dữ liệu và dịch vụ nội bộ.

Ý tưởng chính của Zero Trust là biến điểm thực thi tập trung thành nhiều điểm kiểm tra vi mô trong mọi đường dẫn ứng dụng của bạn , bao gồm cả API. Cho dù đó là yêu cầu bên ngoài truy cập nội bộ, điện thoại di động hay PC, lệnh gọi API hay yêu cầu HTTP, nhân viên bình thường hay CEO, không ai có thể tin cậy được.

Để đạt được mục tiêu như vậy một cách hiệu quả mà không làm dừng hoặc làm chậm các ứng dụng của bạn, việc điều phối và tự động hóa sẽ là các bước quyết định quan trọng.

Tại sao Điều phối và Tự động hóa lại quan trọng đối với Bảo mật API Zero Trust?

ZTA, NIST SP800–207 | Hình ảnh của tác giả

Để giải thích sự cần thiết của cả hai, chúng ta hãy xem xét kỹ hơn một trụ cột của Kiến trúc Zero Trust — Niềm tin truy cập của người dùng/thiết bị . Phương thức phòng vệ này tương tự như việc bạn xuất trình hộ chiếu tại trạm kiểm soát sân bay và chứng minh thư để mua rượu.

Không có danh tính và quyền hạn tương ứng, không thể vào hệ thống liên quan. Đây là lúc API Gateway phát huy tác dụng mạnh mẽ, vì nó cung cấp một số tính năng xác thực chính:

• Tự động xoay phím
• Tích hợp với nhiều hệ thống xác thực như OKTA và Auth 2.0
• Hỗ trợ mã hóa lưu lượng TLS và mTLS

Có hai thành phần cốt lõi của Niềm tin người dùng và thiết bị:

• Quản lý danh tính và quyền truy cập
• Cổng API với bảo mật tích hợp

Hãy tưởng tượng thêm thiết bị nhận dạng trong tất cả các trung tâm giao thông , chẳng hạn như sân bay và đường sắt cao tốc. Bạn cũng phải hiểu tất cả các tuyến đường đến và đi từ tất cả các đầu mối giao thông và thực hiện các biện pháp bảo vệ.

Trong một doanh nghiệp lớn, sẽ có hàng trăm hệ thống, hàng chục nghìn API và microservice cũng như hàng trăm nghìn khách hàng. Trừ khi chúng tôi có nguồn lực và thời gian không giới hạn, nhóm DevOps, Bảo mật hoặc Ứng dụng không thể xác định và thêm thủ công hàng trăm nghìn kiểm tra nhận dạng vi mô trong các ứng dụng hiện đại.

Tất cả các trụ cột khác của Kiến trúc Zero Trust, Ứng dụng, Khối lượng công việc và Dữ liệu cũng yêu cầu logic tương tự để áp dụng. Sự cần thiết là một giải pháp:

1. Nó sử dụng kiến trúc hiện đại,
2. Hoạt động trong môi trường không đồng nhất,
3. Giảm thiểu những rủi ro này (không chỉ hàng hóa), và
4. Thực hiện tất cả điều này theo cách tự động trên các môi trường nhiều đám mây
5. (tùy chọn) mã nguồn mở, như vậy để cho phép sự nhanh nhẹn và sáng tạo của công nghệ.

Bảo mật API Idea Zero Trust trông như thế nào?

Để áp dụng các môi trường phức tạp và không đồng nhất trong API, giải pháp Bảo mật API Zero Trust phải có khả năng được triển khai ở nhiều định dạng và do đó hỗ trợ các cài đặt khác nhau , ví dụ:

• Bộ chứa Docker,
• Một proxy ngược độc lập,
• Đại lý cho máy chủ web/ứng dụng, hoặc
• Được nhúng trong Bộ điều khiển xâm nhập Kubernetes.

Với sự hỗ trợ của đám mây và kiến trúc ứng dụng hiện đại, tự động hóa và khả năng mở rộng sẽ được quan tâm.

Nhưng để duy trì sự phối hợp, “tác nhân” (hoặc điểm thực thi vi mô) phải có khả năng được triển khai trên ứng dụng hiện có mà không thay đổi kiến trúc hiện có trong khi vẫn đảm bảo độ trễ tối thiểu và khả năng kiểm soát tối đa.

Sau khi xem xét các yếu tố hình thức triển khai và kiến trúc, điều cần thiết là mức độ bảo mật không bị suy giảm. Để Zero Trust thực sự được thông qua, quá trình xử lý bảo mật phải được thực hiện cục bộ mà không truyền sang các đám mây hoặc công cụ khác, chẳng hạn như hộp cát đám mây để phân tích.

Nếu các bên bên ngoài không nằm trong tầm kiểm soát của chúng tôi, thì việc xác minh độ tin cậy truy cập Dữ liệu/Mạng sẽ khó khăn. Có một số lợi ích khác của việc làm như vậy tại địa phương, chẳng hạn như:

• Dữ liệu nhạy cảm không rời khỏi môi trường được bảo vệ.
• Bạn không cần chia sẻ chứng chỉ và khóa riêng với bên thứ ba.
• Không phụ thuộc vào thời gian hoạt động của bên thứ 3 để xử lý lưu lượng.

Phần cuối cùng là xem xét sự phối hợp. Lý tưởng nhất là chúng ta cần một giải pháp có thể truyền vào môi trường ứng dụng trong khi một người điều phối có thể quản lý các tác nhân đó và đảm nhận các hoạt động sau:

• đăng ký/hủy đăng ký đại lý
• cập nhật chính sách
• cập nhật cấu hình
• cập nhật phần mềm
• khai thác gỗ và
• Đồng bộ hóa dữ liệu.

Nói tóm lại, Zero Trusted API Security phải ở nhiều dạng khác nhau để truyền vào môi trường ứng dụng hiện đại. Trong khi đó, giải pháp tốt nhất sẽ có thể cung cấp khả năng điều phối và tất cả các chức năng bảo mật mà các giải pháp truyền thống có thể cung cấp.

Vì vậy, như bạn đã biết, không có niềm tin không phải là hoàn hảo. Các giải pháp không tin tưởng không thể bảo vệ hoàn toàn trước các cuộc tấn công kỹ thuật xã hội hoặc zero-day, mặc dù chúng có thể làm giảm đáng kể bề mặt và tác động của cuộc tấn công.

Từ cuối cùng

API đã trở thành hệ thần kinh trung ương của các ứng dụng hiện đại, mang thông tin và dữ liệu quan trọng từ phần này sang phần khác của ứng dụng hoặc từ ứng dụng này sang ứng dụng khác. Do đó, bảo mật API nên được ưu tiên khi bảo mật ứng dụng. Điều này đặc biệt đúng đối với các API công khai, với người dùng trên toàn thế giới truy cập các thành phần phần mềm và dữ liệu nhạy cảm.

Việc áp dụng Zero Trust Framework chuyển trọng tâm từ một biện pháp bảo vệ duy nhất sang các trụ cột khác nhau (Người dùng, Thiết bị, Mạng, Ứng dụng và Dữ liệu). Điều đó có thể giúp bạn đảm bảo rằng mọi phần của quyền truy cập API, dù bên trong hay bên ngoài chu vi, đều theo cách tiếp cận ít đặc quyền nhất và được giám sát liên tục.

Cảm ơn bạn đã đọc. InfoSec có thể ở bên bạn🖖.