VietNetwork.Vn

Các chiến lược đám mây hiện đại sử dụng nhiều API để truy cập có kiểm soát, tương tác vào các dịch vụ được lưu trữ. Nhưng quyền truy cập chỉ được kiểm soát nếu các API được triển khai an toàn và chúng không dễ bị lạm dụng.


1. API web

Giao diện lập trình ứng dụng (API) cho phép phần mềm nói chuyện với phần mềm khác. Điều đó đòi hỏi một tập hợp các thông số kỹ thuật. Phải có một tập hợp các chức năng được lập thành văn bản mà điểm cuối API cung cấp và các quy tắc về những gì ứng dụng khách API phải làm để sử dụng các chức năng đó. Loại và định dạng của dữ liệu do API trả về phải được xác định cho từng hàm. Bạn thường muốn hạn chế ai có quyền truy cập vào API, vì vậy các ứng dụng khách API phải xác thực theo một cách nào đó. Trong một API bị hạn chế, các yêu cầu chỉ phải được phục vụ khi điểm cuối API đã xác minh rằng yêu cầu là hợp pháp.

Như với tất cả việc phát triển phần mềm, phương pháp bảo mật theo thiết kế tốt hơn nhiều so với việc xây dựng nó trước, bảo mật nó sau đó. Thảm họa API Peloton minh họa điều này một cách hoàn hảo. Việc triển khai API thiếu sót — hiện đã được khắc phục — cho phép thực hiện các lệnh gọi API chưa được xác thực.

Bất kỳ ai cũng có thể lấy lại dữ liệu cá nhân về bất kỳ khách hàng nào của Peloton. "Bản sửa lỗi" đầu tiên chỉ đơn giản là hạn chế API đối với chủ sở hữu Peloton. Điều này chỉ tốt hơn một chút. Với bản sửa lỗi cuối cùng được thực hiện, dữ liệu của người dùng Peloton cuối cùng cũng ở chế độ riêng tư, trừ khi họ chọn chia sẻ nó một cách rõ ràng.

Có nhiều ví dụ khác về các API yếu hoặc được thiết kế kém. Facebook đã tiết lộ dữ liệu cá nhân của 533 triệu người dùng vì một API cho phép bất kỳ ai tìm kiếm cơ sở dữ liệu bằng cách sử dụng số điện thoại — với tốc độ lên đến 1000 mỗi phút.

Hơn 80 phần trăm lưu lượng truy cập internet là lưu lượng API. Đó là rất nhiều API. Tính đến giữa năm 2021,  10 rủi ro bảo mật hàng đầu của Dự án Bảo mật Ứng dụng Web Mở  (OWASP) đã không thay đổi trong vài năm. Đáng buồn thay, những sai lầm giống nhau dẫn đến những lỗ hổng giống nhau đang được lặp đi lặp lại. Và điều đó quá hấp dẫn để tội phạm mạng bỏ qua.

2. Các bên liên quan phát triển

Các API thường ít được bảo vệ tốt hơn các trang web và ứng dụng dành cho thiết bị di động. Các yêu cầu về hiệu suất có thể buộc nhóm phát triển tập trung vào việc làm cho chúng tinh gọn và có ý nghĩa. Tinh gọn đến mức chúng chứa rất ít — nếu có — mã dành để bảo vệ API và dữ liệu mà chúng bảo vệ. Một API được thiết kế kém hoặc triển khai không tốt sẽ có những điểm yếu có thể bị khai thác. Cách khắc phục thích hợp không phải là dán Band-Aid lên nó và cố gắng bịt các lỗ. Bạn cần sửa mã hoặc có thể là logic nghiệp vụ đã được mô hình hóa thành API.

Khi bạn có nhiều thành phần phần mềm nói chuyện với nhau qua các lệnh gọi API — chẳng hạn như microservices — thì rất khó phát hiện ra lỗi quy trình của lớp nghiệp vụ. Mã của bạn có thể vượt qua bài kiểm tra đơn vị, hồi quy và các bài kiểm tra khác. Bạn có thể không gặp sự cố. Tất cả nhật ký của bạn đều sạch sẽ. Nhưng điều đó không có nghĩa là logic là đúng, cũng như tất cả các lỗ hổng có thể đã được xem xét. Đưa nhóm bảo mật và nhóm phát triển của bạn lại với nhau có thể mang lại những thông tin chi tiết đáng ngạc nhiên.

Nhóm phát triển chịu trách nhiệm viết các API cung cấp chức năng cần thiết. Nhóm bảo mật chịu trách nhiệm bảo vệ dữ liệu đang được phục vụ qua API. Cả hai đều là những bên liên quan trong sự thành công của quá trình phát triển. Các nhà phát triển sẽ không bao giờ nghĩ về bảo mật, các mối đe dọa và các cuộc tấn công như đội bảo mật. Tại sao không mang theo cả hai bộ chuyên môn để giải quyết vấn đề?

3. Các loại tấn công

Các kiểu tấn công phổ biến bạn sẽ gặp có thể được nhóm lại theo kỹ thuật tấn công của chúng.

• Credential Stuffing : Điều này tương tự như các cuộc tấn công brute-force bằng mật khẩu, nhưng nó sử dụng thông tin đăng nhập API thay vì mật khẩu tài khoản người dùng.
• Các cuộc tấn công tiêm : Trong một cuộc tấn công tiêm, tội phạm mạng thêm các hướng dẫn máy tính vào các yêu cầu API của chúng theo cách mà các hướng dẫn được nhúng hoạt động dựa trên điểm cuối API. SQL injection  là một cuộc tấn công khai thác cơ sở dữ liệu SQL. Thông thường, thật dễ dàng để tìm ra phần tử văn bản nào trong lệnh gọi API sẽ được đưa vào các câu lệnh SQL. Việc thêm các câu lệnh SQL vào các lệnh gọi hàm API đó có thể dẫn đến các đoạn mã SQL đó được máy chủ SQL điểm cuối API thực hiện. Cross-site scripting  là một cuộc tấn công tương tự trong đó các hướng dẫn được nhúng bằng ngôn ngữ kịch bản, thường là JavaScript.
• Từ chối dịch vụ phân tán (DDoS) : Các cuộc tấn công này rất giống với các cuộc tấn công DDoS làm ngập một trang web với lưu lượng truy cập, ngăn không cho nó phục vụ các yêu cầu chính hãng. Các cuộc tấn công DDoS nhằm vào các điểm cuối API đang ngày càng phổ biến với các tác nhân đe dọa.
• Man-in-the-Middle (MitM)  Các cuộc tấn công này dựa trên việc chặn lưu lượng truy cập giữa một ứng dụng khách API chính hãng, vô tội và điểm cuối API. Nếu thông tin xác thực API được thu thập, chúng có thể được sử dụng để kết nối lại bằng cách giả mạo là ứng dụng khách API chính hãng. Đôi khi các lệnh gọi API được thực hiện từ máy khách chính hãng được sửa đổi để điểm cuối API thực hiện những gì kẻ tấn công muốn, không phải những gì khách hàng thực sự muốn.

4. Bảo vệ API của bạn

Khi bạn đang tìm cách bảo vệ một tập hợp con của cơ sở hạ tầng CNTT của mình, bạn có thể muốn tìm kiếm các giải pháp cụ thể hoặc mới lạ. Nhưng đừng quên những điều cơ bản về an ninh mạng.

4.1. Định lượng những gì bạn đang giải quyết

Nếu bạn không biết những gì bạn có, bạn không thể quản lý nó. Bạn phải xác định và mô tả đặc điểm của tất cả các API mà bạn sử dụng, cho dù bạn đã tạo chúng hay chưa. Kết quả kiểm tra API của bạn có thể tiết lộ các cơ hội để đơn giản hóa hoặc hợp lý hóa việc sử dụng API của bạn. Nó cũng sẽ làm nổi bật bất kỳ API cũ hoặc không có tuổi cần được cập nhật hoặc tắt.

Khi bạn biết mình có những API nào, chúng làm gì và cách chúng được bảo vệ và phục hồi, bạn có thể ghi lại chiến lược bảo mật API của mình. Sử dụng cơ hội để thiết lập các quy tắc nền tảng cho sự phát triển theo hướng bảo mật và lập kế hoạch cho lộ trình API của bạn.

Dữ liệu nào có thể truy cập được thông qua các lệnh gọi API? Đó là thông tin nhận dạng cá nhân hay nhạy cảm theo một cách nào đó? Phân loại dữ liệu của nó là gì? Nếu các chính sách bảo vệ dữ liệu của bạn được triển khai đúng cách, chúng sẽ chứa thông tin này. Xem xét nghiêm túc việc truy cập vào dữ liệu. Bạn có đang tiết lộ nhiều dữ liệu hơn mức cần thiết không?

4.2. Làm cho các API của bạn trở nên ngắn gọn

Muốn làm cho API của bạn trở thành một trải nghiệm phong phú cho người tiêu dùng dữ liệu có thể dẫn đến báo cáo quá mức và không cần thiết phải cung cấp thông tin chi tiết về chính điểm cuối API. Thông tin về chủ thể dữ liệu, khóa mã hóa và mã thông báo xác thực đều đã bị rò rỉ bởi các API quá dài dòng. Một cách tiếp cận được cân nhắc và an toàn hơn là trả về lượng dữ liệu tối thiểu mà ứng dụng khách API cần để thực hiện chức năng được yêu cầu.

Điều này quay trở lại nguyên tắc ít sự cho phép nhất, một yếu tố quan trọng của an ninh mạng. Bạn chỉ nên cấp cho người dùng, quy trình, thiết bị IoT hoặc bất kỳ thứ gì khác tương tác với CNTT của bạn các đặc quyền tối thiểu cần thiết để vai trò hoặc chức năng của họ được thực hiện. Làm tương tự với các API của bạn.

4.3. Sử dụng mã hóa

Mã hóa lưu lượng API của bạn bằng TSL, phiên bản kế thừa của SSL. Đừng bị hướng dẫn bởi giá trị của dữ liệu. Hãy nhớ rằng bạn cũng đang bảo vệ mã thông báo xác thực ứng dụng khách API. Những kẻ tấn công có thể không quan tâm đến dữ liệu. Tuy nhiên, nếu họ có được mã thông báo xác thực, họ có thể sử dụng API để trích xuất thêm manh mối về hệ thống của bạn để họ có thể thực hiện các cuộc tấn công khác nhau.

4.4. Giá trị xác thực và đầu vào

Rõ ràng, bạn cần phải có một hệ thống xác thực mạnh mẽ. Đừng phát minh lại bánh xe. Bất cứ khi nào có thể, hãy sử dụng giải pháp được công nhận như OAuth2.0. Bạn có thể cảm thấy rằng các API nội bộ không cần xác thực. Nhưng bạn có thể đảm bảo rằng một API nội bộ sẽ không được công khai do nhầm lẫn, có lẽ vì nó đang được sử dụng lại trong một dự án khác không?

Không bao giờ chấp nhận đầu vào từ một API một cách mù quáng mà không xác thực nó trước. Quét nó để tìm nội dung không đúng định dạng, tập lệnh nhúng và các cuộc tấn công chạy quá tốc độ.

Lưu ý về tần suất yêu cầu kết nối và áp dụng các biện pháp giới hạn tốc độ hợp lý. Có phải khách truy cập tần suất cao là ai đó đang cố gắng cưỡng bức họ vào hay họ đang cố lấy dữ liệu ra khỏi cơ sở dữ liệu của bạn, yêu cầu theo yêu cầu?

4.5. Công nghệ Đồng minh

Tường lửa ứng dụng web (WAF) giúp bảo vệ các trang web, ứng dụng được lưu trữ và API bằng cách lọc và giám sát lưu lượng truy cập đến và đi từ tài nguyên được bảo vệ. Chúng có thể phát hiện các cuộc tấn công như tập lệnh chéo trang web và chèn SQL, trong số các cuộc tấn công khác. WAF là một công nghệ bảo vệ lớp ứng dụng, (cấp 7 trong mô hình ISO), không phải là một giải pháp phù hợp cho tất cả các trang web hoặc bảo mật API của bạn. Chúng được triển khai tốt nhất như một phần tử trong một bộ phòng thủ nhiều lớp.

Một cổng API nằm giữa điểm cuối API và các ứng dụng khách API. Họ môi giới các yêu cầu API giữa các máy khách và điểm cuối API, đôi khi chia nhỏ một yêu cầu thành các phần nhỏ hơn được phục vụ bởi các microservices khác nhau. phản hồi được đối chiếu và gửi lại cho ứng dụng khách API. Các cổng API có thể tích hợp hoặc cung cấp các phương tiện xác thực và giới hạn tỷ lệ. Có sẵn các cổng API phần mềm như một dịch vụ, mang lại tính khả dụng cao và tự động mở rộng quy mô.

5. Các API ở Tiền tuyến

Với sự gia tăng không ngừng của đám mây và microservices, các API tự nhận thấy mình đang ở tuyến đầu của các cuộc tấn công mạng. Tội phạm mạng thích tỷ lệ cược khi chúng xếp chồng lên nhau có lợi cho chúng. với rất nhiều API ngoài kia, không thể tránh khỏi việc nhiều API trong số đó sẽ được bảo vệ kém hoặc thậm chí không được bảo vệ. Đừng để chúng là của bạn.