Gating IoT


Phan Việt Hải
3 năm trước
Hữu ích 2 Chia sẻ Viết bình luận 0
Đã xem 8502

Xe hơi của bạn. Máy nướng bánh mì của tôi. Đèn của chúng tôi. Bộ điều nhiệt của hàng xóm.

Với trung bình 7,8 thiết bị được kết nối mỗi nhà, theo các cuộc khảo sát gần đây , có gấp đôi số lượng vật phẩm trong nhà, trung bình 3,14 người / hộ gia đình ở Mỹ trong năm 2015 .

Và tất cả trong số họ đang nói chuyện với nhau. Tuy nhiên, không phải tất cả đều nói chuyện với nhau, mặc dù nền tảng cho điều đó được đặt ra rõ ràng. Nhưng tất cả trong số họ nói chuyện với các ứng dụng, nói chuyện với họ qua Internet.

Khi bạn hoặc tôi tương tác với ứng dụng đó, chúng tôi sẽ thực hiện thông qua HTTP (hy vọng được bảo mật). Cho dù đó là thông qua một ứng dụng di động gốc sử dụng API hoặc ứng dụng web hiện đại đều không liên quan; có thể nói rằng cả hai đều làm như vậy thông qua HTTP.

Nhưng khi mọi thứ báo cáo, không rõ ràng bằng cách sử dụng HTTP. Ồ, một số làm, chắc chắn. Nhưng khi yếu tố hình thức cho những điều này giảm đi, việc quản lý sức mạnh và tính toán theo cách hỗ trợ cho các khung và giao thức nặng hơn, như HTTP trở nên ngày càng khó khăn hơn. Đó là lý do tại sao các giao thức dành riêng cho IoT đã xuất hiện. Các giao thức như MQTT (Vận chuyển từ xa MQ) và AMQP (Giao thức xếp hàng tin nhắn nâng cao) loại bỏ sự phụ thuộc vào HTTP (nhưng vẫn dựa trên TCP / IP) và ngay cả những giao thức như CoAP (Giao thức ứng dụng bị ràng buộc - RFC 7252 ), nhằm tìm cách giảm thiểu tác động của HTTP bằng cách tối ưu hóa một tập hợp con đặc biệt cho giao tiếp giữa máy với máy (M2M).

Các mô hình xuất bản / đăng ký (thường được đơn giản hóa thành pub / sub cho ngắn gọn) không có gì mới trong thế giới của các ứng dụng. Xếp hàng tin nhắn là một trong những cách mà các ứng dụng luôn chia sẻ dữ liệu, từ rất lâu trước khi Internet trở nên phổ biến. Trước đó, chúng tôi đã triển khai bằng C / C ++. Sau đó, Java đã chiếm lĩnh thế giới (và Internet) bằng cơn bão và chúng tôi đã học cách sử dụng JMS (Dịch vụ tin nhắn Java).

Tất cả các giao thức dựa trên pub / sub có thể được chắt lọc theo một khái niệm cơ bản, duy nhất: các tin nhắn được định tuyến theo kiểu LINE dựa trên các chủ đề.

Điều này nghe có vẻ quen thuộc với những bạn phải định tuyến đường URIs. Định tuyến trang, định tuyến ứng dụng, chuyển đổi nội dung. Chúng tôi gọi nó là nhiều thứ khác nhau, nhưng cuối cùng, đó là cùng một khái niệm. Đưa ra một mã định danh duy nhất trong lớp ứng dụng, các yêu cầu được chuyển đến điểm cuối được chỉ định. Với các giao thức pub / sub là một nhà môi giới tin nhắn. Đối với URI, nó thường là một ứng dụng hoặc API được lưu trữ trên máy chủ web.

Sự khác biệt với các giao thức IoT là phần lớn chúng không dựa trên HTTP. Chúng chạy trên đỉnh TCP / IP nhưng được thiết kế có mục đích là nhẹ. Điều này có nghĩa là dữ liệu (đang phát triển) có nguồn gốc từ các thiết bị 7.8 trong nhà bạn đang được vận chuyển qua một thứ khác ngoài HTTP.

Điều này là người nhận (người môi giới tin nhắn) cũng cần phải được thu nhỏ và bảo mật. Một trong những điều phức tạp, như đã từng, đó là những thứ mà Keith muốn có những kết nối bền bỉ. Đó là bởi vì giao tiếp là hai chiều và không đồng bộ. Thiết lập các kết nối thông qua TCP là điều dễ hiểu và đó là một công việc tốn nhiều công sức tiêu tốn các chu kỳ CPU đưa độ trễ vào phương trình. Độ trễ mà người tiêu dùng ngày nay không chịu được. Kết nối liên tục cho phép mọi thứ liên tục liên lạc nếu cần thiết và nhận được các bản cập nhật với tính trực tiếp không chỉ mong muốn đối với một số người tiêu dùng, mà còn cần thiết cho những người khác (IoT công nghiệp phụ thuộc vào tính trực tiếp). Điều này gây áp lực cho các nhà môi giới về năng lực, bởi vì mọi kết nối đều dựa vào tổng năng lực của họ để xử lý mọi việc. Điều đó thường có nghĩa là một số loại proxy có khả năng cân bằng tải trước các nhà môi giới để đảm bảo tin nhắn được gửi đến đích của họ. Rốt cuộc, các thiết bị tạo ra rất nhiều dữ liệu và chúng sẽ hoạt động 24/7.

Điều đó, đến lượt nó, gây áp lực lên các ops bảo mật để đảm bảo rằng mọi kết nối đều có giá trị. Bạn không muốn lãng phí tài nguyên trên một kết nối đến một thứ không hợp lệ. Bạn không muốn sử dụng hết các thông báo xử lý chu trình CPU không hợp lệ.

Trong khi hầu hết các cuộc tấn công ngày nay tập trung vào khai thác sức mạnh của hàng triệu (nghĩa là hàng triệu) thiết bị bị xâm nhập trên Internet, giống như bất kỳ dịch vụ nào đối mặt với công chúng, các nhà môi giới tin nhắn IoT trong trung tâm dữ liệu (đám mây hoặc tại chỗ) dễ bị tấn công , và đặc biệt, các cuộc tấn công DoS. Đó là bởi vì họ dựa vào khái niệm chủ đề như một trình kích hoạt xử lý cốt lõi. Các chủ đề có thể bao gồm nhà ở nhiệt độ / nhiệt độ và hoặc nhà / nhiệt độ / cảnh báo , hoặc đơn giản là nhà ở / # . Những chủ đề này thông báo cho người môi giới tin nhắn phải làm gì và làm thế nào để xử lý dữ liệu.

Nhưng điều gì xảy ra nếu nó nhận được một chủ đề mà nó không hiểu? Và nếu điều đó xảy ra rất nhiều. Giống như, nhiều hơn các nhà môi giới có thể xử lý?

Chính xác. Tài nguyên được tiêu thụ không cần thiết và nhà môi giới có thể trở nên quá tải và không thể xử lý các tin nhắn hợp pháp. Đó là cùng một câu chuyện cũ - làm cạn kiệt dịch vụ điểm cuối và từ chối.

Vì vậy, giống như hầu hết các dịch vụ dựa trên web, công khai, một nhà môi giới IoT - cho dù nói MQTT hoặc CoAP hoặc một số giao thức pub / sub khác - cần một số mức độ bảo vệ chống lại các nỗ lực độc hại để gây nhầm lẫn và gây nhầm lẫn. Do đó, bạn sẽ cần phải chuyển qua IoT.

Đây là nơi tôi lưu ý rằng đây sẽ là một thị trường mới nổi. Giống như XML và SOA và API trước đó, sẽ có các cổng IoT. Chúng sẽ được xây dựng với tiền đề bảo vệ và nhân rộng các nhà môi giới tin nhắn, và họ sẽ nói ngôn ngữ của IoT. Tuy nhiên, để làm được điều đó, cổng sẽ cần phải nói các giao thức bảo mật của người dùng, cũng như TLS. Dữ liệu gửi đến có thể độc hại, nhưng thật khó để nói dưới tất cả những mã hóa đó. Cổng thông tin, sau đó, sẽ cần khả năng hiển thị để xem qua các tin nhắn và kiểm tra các chủ đề để đảm bảo tính hợp lệ trước khi chuyển chúng cho các nhà môi giới tin nhắn.

Chúng tôi có thể không gọi chúng là cổng IoT. Chúng tôi có thể gọi chúng là proxy IoT hoặc giải quyết một giao thức cụ thể và gọi chúng là proxy hoặc cổng MQTT. Nhưng vào cuối ngày, họ sẽ hoạt động theo cùng các nguyên tắc đã bảo vệ và mở rộng các giao thức cho phép giao tiếp qua Internet. Dù chúng được gọi là gì, những giải pháp này sẽ cần để có thể nói tiếng Anh về ngôn ngữ của IoT, cụ thể là các giao thức như MQTT, CoAP và AMQP. Đó là bởi vì họ phải có khả năng hiểu cách xác định chủ đề và thực thi logic để xác định tính hợp lệ của các chủ đề đó, để ngăn chặn các nhà môi giới lãng phí một cách không cần thiết các tài nguyên quý giá để xử lý và xử lý những chủ đề không hợp pháp và thực tế có thể là độc hại.

Nếu chúng ta đã học được bất cứ điều gì từ các giao thức ứng dụng và nhắn tin trong quá khứ, thì chúng có thể và sẽ bị thao túng và khai thác cho các mục đích bất chính. Cho dù đó là để lọc dữ liệu hay gây ra sự từ chối dịch vụ, những kẻ tấn công sẽ nhắm mục tiêu vào các hệ thống mà thị trường IoT đang phát triển nhanh chóng này phụ thuộc. Một ounce phòng ngừa vẫn còn giá trị một pound chữa bệnh.

Giữ an toàn ngoài đó.

Hữu ích 2 Chia sẻ Viết bình luận 0
Đã xem 8502