#security #rest #enterprise #restful-authentication
#Безопасность #rest #Предприятие #restful-аутентификация
Вопрос:
Интересно, действительно ли веб-сервис RESTful является ответом в моем случае корпоративного приложения, где есть некоторые проблемы безопасности, такие как предотвращение атак «человек посередине», обеспечение подключения доверенного клиента, уверенность клиента в том, что он действительно разговаривает с реальным сервером и т.д.
Является ли HTTPS решением? Прочитал некоторые высказываемые опасения по поводу его адекватности и оснащения, хотя с не очень сильным опытом в области ИТ / безопасности приложений не совсем понимаю, почему так!
Я вижу, как о ReST говорят (/ бредят) и его проецируют как «вещь», и действительно вижу, как набирает обороты его внедрение, но, похоже, не могу понять, почему проблема безопасности не вызывает такой большой озабоченности, и если это так, то что с этим можно сделать.
Комментарии:
1. Что вас беспокоит по поводу HTTPS?
2. @darrel-miller, прояснил мой вопрос дальше. Честно говоря, я не знаю, подходит HTTPS или нет, поскольку я только начал читать ReST, и, на удивление, в тексте ничего не говорится о безопасности. Я не могу понять, как можно говорить о предоставлении списка клиентов, сведений о клиенте, списка заказов, сведений о заказе по HTTP, даже если это для корпоративной интрасети. Это наводит меня на мысль, что текст был простым введением, и в нем еще многое предстоит понять.
3. Внимательно прочитайте о HTTPS и SSL / TLS, чтобы удовлетворить ваши опасения по поводу протокола. Подразумеваемый смысл Даррела заключается в том (я предполагаю), что HTTPS, скорее всего, удовлетворит вашим требованиям безопасности, и я был бы согласен.
Ответ №1:
Если вы действительно серьезно относитесь к обеспечению безопасности своего сервиса и избежанию атак типа «человек посередине», вам следует выдавать сертификаты своим клиентам и принимать запросы, подписанные только этими сертификатами. Это требует больше работы для вас и для ваших клиентов, но в условиях предприятия дополнительные усилия могут того стоить. Это определенно вариант, который стоит рассмотреть.
Ответ №2:
Из коробки у вас не будет никакого типа безопасности на уровне сообщений, и вам нужно будет использовать HTTPS для обеспечения безопасности на транспортном уровне.
Я видел, как люди пытались использовать подписанные каналы atom, но это ничто по сравнению с уровнем стека WS-*, который поставляется с SOAP.
Комментарии:
1. спасибо за ответ. Между публикацией моего вопроса и сейчас я еще немного почитал и, таким образом, могу оценить ваш ответ. Некоторые предложили в качестве ответа OAuth2.0, а разработчик / изобретатель OAuth продолжает заявлять о недостатках OAuth2.0 в своем блоге. Мое текущее понимание заключается в том, что конструкции OAuth2.0 (все из которых я пока не понимаю), наряду с SSL, похоже, решают все текущие проблемы безопасности. Однако, это единственное решение или есть другие способы? Крупномасштабный SSL-сертификат mgt / admin с течением времени кажется довольно сложной операцией.