Блог

Я изучаю Амазонку Нептун и заметил, что:

1. Аутентификация IAM по умолчанию не включена
2. Для аутентификации IAM требуется подпись AWS v4 для вызовов API, что увеличивает сложность приложения

По умолчанию, похоже, Amazon Neptune использует анонимную аутентификацию, так как мне не нужно было предоставлять какие-либо ключи API, комбинации имени пользователя / пароля или сертификаты для аутентификации. Кроме того, образец кода, предоставленный AWS, не содержит никаких сведений об аутентификации.

Похоже, что единственными параметрами безопасности по умолчанию для Amazon Neptune являются группы безопасности VPC сетевого уровня.

Согласно What is Neptune? документации, служба утверждает, что она «очень безопасна». На мой взгляд, служба, которая по умолчанию не поддерживает аутентификацию на уровне приложений, не является «высокозащищенной».

Нептун обеспечивает несколько уровней безопасности для вашей базы данных. Функции безопасности включают изоляцию сети с помощью Amazon VPC и шифрование в режиме покоя с использованием ключей, которые вы создаете и контролируете с помощью службы управления ключами AWS (AWS KMS). В зашифрованном экземпляре Neptune данные в базовом хранилище зашифрованы, как и автоматические резервные копии, моментальные снимки и реплики в том же кластере.

Вопрос: Почему Amazon Neptune по умолчанию использует небезопасную конфигурацию и есть ли способ включить аутентификацию без использования сложной встроенной аутентификации IAM?

У вас есть несколько очень важных моментов, поэтому позвольте мне подробно их рассмотреть, предоставив некоторый контекст.

По умолчанию, похоже, Amazon Neptune использует анонимную аутентификацию..

Это сделано намеренно по какой-то причине. Языки запросов, которые сейчас поддерживает Neptune, — это Gremlin и SPARQL, оба из которых построены поверх HTTP/HTTPS без какой-либо аутентификации (базовая аутентификация поддерживается в Gremlin, но в любом случае это не то, что клиенты используют в производстве. Мне понадобилась бы по крайней мере какая-то форма проверки подлинности дайджеста сообщений, чтобы назвать ее безопасной, но, к сожалению, спецификация языка не включает это). Поскольку эти языки открыты, существует множество клиентского кода с открытым исходным кодом, который предполагает, что они имеют дело с не прошедшей проверку подлинности конечной точкой. В результате, исключительно с точки зрения принятия, Нептун решил сохранить свой уровень запросов не прошедшим проверку подлинности по умолчанию. Если вы изучите другие механизмы БД в AWS (скажем, Aurora MySQL), механизм БД поддержки поддерживает аутентификацию по умолчанию.

Это не означает, что это правильно, поэтому я позволю кому-нибудь из сообщества Gremlin/SPARQL прокомментировать, должна ли спецификация применять аутентификацию в качестве позиции по умолчанию или нет.

Похоже, что единственными параметрами безопасности по умолчанию для Amazon Neptune являются группы безопасности VPC сетевого уровня.

SG предоставляют сетевые списки управления доступом, и мы по умолчанию поддерживаем TLS 1.2 (начиная с новейших версий движка), так что это также укрепляет ваше соединение клиент -> бд.

Служба утверждает, что она «очень безопасна». На мой взгляд, служба, которая по умолчанию не поддерживает аутентификацию на уровне приложений, не является «высокозащищенной».

В дополнение к описанным выше деталям, «высокозащищенный» аспект Neptune не ограничивается только подключением клиент -> бд. Ваши данные реплицируются 6 способами и хранятся в 3 АЗС. Это требует большой связи не только из БД, но и внутри резервных узлов хранения. Все эти коммуникации защищены стандартными отраслевыми протоколами безопасности. Шифрование в состоянии покоя для распределенного хранилища само по себе является совершенно интересным примером. Те же стандарты применяются к доступу оператора к машинам, аудиту, безопасности данных, которые снимаются и восстанавливаются и т. Д. и т. Д. Короче говоря, я согласен с тем, что по умолчанию должна быть включена аутентификация SigV4 (или какой-либо открытый стандарт), я хочу убедиться, что вы получите некоторую ясность в том, почему мы утверждаем, что являемся высокозащищенной БД, как и любой другой продукт, предоставляемый AWS.

Есть ли способ включить аутентификацию без использования сложной встроенной аутентификации IAM?

SigV4-это стандарт, который поддерживает большинство сервисов AWS. Я согласен, что было бы намного проще, если бы существовал SDK, который клиенты могли бы напрямую использовать. Мы выпустили плагины SigV4 для некоторых клиентов (особенно Java и Python), и на самом деле у него довольно хорошее понимание. Попробуйте и поделитесь отзывами о том, какие области интеграции показались вам болезненными, и мы были бы более чем рады взглянуть.

ПРАВКА 1: Обсуждение операции здесь касалось безопасности между клиентом и базой данных, поэтому методы обеспечения безопасности в непрозрачном хранилище резервных данных, которые я привел выше, на самом деле не актуальны. Другими словами, обсуждение здесь полностью посвящено API плоскости данных Нептуна и тому, можем ли мы быть в безопасности по умолчанию, а не по желанию.