Создание микросервисов

Рабочие задачи по управлению сертификатами здесь еще более обременительны, чем при использовании сертификатов на стороне сервера. И дело не только в ряде основных проблем, касающихся создания большего количества сертификатов и управления ими, а скорее в тех сложностях, которые касаются самих сертификатов. И вы должны быть готовы к тому, чтобы потратить много времени на определение причин, по которым сервис не признает то, что, по вашему мнению, будет совершенно допустимым клиентским сертификатом. И тогда, если произойдет самое худшее, нужно еще взять в расчет сложность аннулирования и повторного выпуска сертификатов. Помочь сможет применение групповых сертификатов, но это не решит всех проблем. Эта дополнительная нагрузка означает, что вы будете присматриваться к использованию данной технологии при особой обеспокоенности о конфиденциальности пересылаемых данных или при отправке данных по сети, не находящейся под вашем полным контролем. Поэтому вы, к примеру, можете принять решение о безопасном обмене только теми данными, которые имеют для сторон особую важность при их отправке по Интернету.

HMAC через HTTP

Как уже говорилось, использовать Basic Authentication через обычный HTTP, если вы обеспокоены компрометацией имени пользователя и пароля, не очень разумно. Традиционной альтернативой служит направление трафика через HTTPS, но у этого способа имеется ряд недостатков. Кроме управления сертификатами, издержки HTTPS-трафика могут стать причиной дополнительной нагрузки на серверы (хотя, если честно, сейчас в таком случае влияние на нагрузку значительно меньше, чем было несколько лет назад), да к тому же имеются сложности с кэшированием такого трафика.

Альтернативный способ подписи запроса, который активно используется API-интерфейсами S3 компании Amazon и является частью OAuth-спецификации, — применение кода проверки подлинности сообщений на основе хеш-функции (HMAC).

При использовании HMAC тело запроса хешируется закрытым ключом и получившийся хеш отправляется вместе с запросом. Затем сервер использует собственную копию закрытого ключа и тело запроса для воссоздания хеша. При совпадении запрос принимается. Приятным обстоятельством является то, что, если где-нибудь на дистанции кто-то проведет какие-либо манипуляции с запросом, хеш не совпадет и сервер будет знать, что запрос был подделан. А закрытый ключ в запросе никогда не пересылается, поэтому он не может быть скомпрометирован в пути! Дополнительным преимуществом является то, что затем трафик может намного легче кэшироваться и издержки на генерирование хешей могут быть намного ниже, чем на обработку HTTPS-трафика (хотя у вас может сложиться и другое мнение).

У этого подхода есть три недостатка. Во-первых, как клиенту, так и серверу нужен общий секрет, который каким-то образом должен быть передан. Как осуществляется его совместное использование? Он должен быть жестко задан на обоих концах, но затем в случае компрометации этого секрета возникнет проблема аннулирования доступа. Если пересылать этот ключ по какому-то альтернативному протоколу, то нужно быть уверенным в том, что этот протокол также обладает весьма высокой степенью безопасности!

Во-вторых, это схема, а не стандарт, поэтому существуют разные способы ее реализации. В результате наблюдается явная нехватка хороших, открытых и практичных реализаций этого подхода. В общем, если этот подход вам интересен, то можете обратиться к дополнительным источникам информации, чтобы разобраться в различных способах его реализации. Я бы предложил просто посмотреть, как он реализован компанией Amazon для ее S3, и скопировать их подход, особенно в использовании рациональной функции хеширования с соответствующим длинным ключом, таким как SHA-256. Стоит также присмотреться к веб-маркерам в формате JSON — JSON web tokens (JWT), поскольку в них реализуется очень похожий подход, который, кажется, набирает обороты. Но при этом имейте в виду, что выполнить все правильно нелегко. Мой коллега работал с командой, которая, занимаясь собственной JWT-реализацией, пропустила одну булеву проверку и сделала недействительным весь свой код аутентификации! Надеюсь, со временем мы увидим реализации библиотек, более пригодные к повторному использованию.

И в-третьих, следует понимать, что этот подход гарантирует только то, что никакая третья сторона не сможет провести манипуляции с запросом и сам закрытый ключ останется закрытым. Все остальные данные в запросе будут по-прежнему видны тем, кто шпионит в сети.

API-ключи

API-ключи используются всеми открытыми API-интерфейсами таких сервисов, как Twitter, Google, Flickr и AWS. API-ключи позволяют сервису идентифицировать того, кто осуществляет вызов, и наложить ограничения на то, что он может сделать. Зачастую ограничения выходят за рамки простого предоставления доступа к ресурсам и могут распространяться на такие действия, как ограничение скорости конкретных абонентов для обеспечения качества предоставления сервиса другим людям.