Защита Кассандры

В этой статье мы обсудим, как мы можем защитить кластер Cassandra, и это включает такие задачи, как аутентификация, авторизация и т. Д., Давайте обсудим их по очереди.

Существует четыре концепции защиты авторизации Cassandra, аутентификации, шифрования и межсетевых экранов.

1. Аутентификация:
   Здесь мы проверим, как мы разрешаем приложениям и пользователям входить в кластер.

2. Авторизация:
   В этом случае мы имеем дело с предоставлением разрешений, которые позволяют пользователю создавать, читать и записывать данные и т. Д. Для доступа к базе данных или объектам базы данных, таким как таблицы и материализованные представления.
3. Шифрование:
   Здесь мы говорим об использовании Secure Socket Layer (SSL), который представляет собой уровни безопасности для защиты связи между клиентами и базами данных Cassandra, а также между узлами кластера.
4. Межсетевые экраны:
   В этом случае мы управляем портом брандмауэра таким образом, чтобы 9042 был клиентским портом для доступа Cassandra (клиента), и нам нужно знать, какие порты вы должны держать открытыми.

Теперь мы собираемся использовать cqlsh с правами администратора. Кассандра имеет встроенную роль Кассандра, и пароль также является Кассандрой. Запрос cqlsh, используемый для доступа к встроенной роли, выглядит следующим образом.

 cqlsh 127.0.0.1 -u кассандра -p кассандра

Выход:

Теперь, если мы попытаемся создать новую роль, изменить Role, Drop Role и т. Д., Мы можем получить следующую ошибку, например

 InvalidRequest: ошибка сервера: 
code = 2200 [Недействительный запрос] message = "org.apache.cassandra.auth.CassandraRoleManager 
                                   не поддерживает ПАРОЛЬ.

Настройка аутентификации:
Вся авторизация и аутентификация выполняются через роли базы данных. Вместо этого используйте команды CREATE ROLE, ALTER ROLE, DROP ROLE, LIST ROLES и LIST_PERMISSIONS.

Чтобы устранить следующую ошибку, измените значения аутентификации по умолчанию в файле cassandra.yaml.

 //значение по умолчанию 
#authenticator: AllowAllAuthenticator  

// устанавливаем значение аутентификатора
аутентификатор: org.apache.cassandra.auth.PasswordAuthenticator  

 //значение по умолчанию 
#authorizer: AllowAllAuthorizer    

// устанавливаем значение авторизатора   
авторизатор: org.apache.cassandra.auth.CassandraAuthorizer

После любых изменений в файле Cassandra.yaml сохраняет файл, а затем перезапускает базу данных и снова входит в cqlsh, используя учетные данные суперпользователя Cassandra по умолчанию.

 cqlsh -u кассандра -p кассандра

Теперь мы собираемся создать новую роль, роль списка, роль отбрасывания и т. Д.

Создайте новую роль:
Для создания новой роли используется следующий CQL-запрос.

 cassandra @ cqlsh> создать пользователя «Пользователь» с паролем «Пользователь»;

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

Выход:

В Cassandra По умолчанию свойство LOGIN в операторе CREATE ROLE имеет значение False. Когда вы создаете роль входа в систему, вы должны установить для этого свойства значение True. мы можем просмотреть роли в базе данных, запросив таблицу system_auth.roles, показанную здесь:

 //system_auth.roles: хранит роли и членов ролей.

выберите * из system_auth.roles;

Выход:

Ролевые разрешения:
Используя запрос cql разрешений ролей, мы можем проверять разрешения, такие как роль может создавать, читать, удалять и т. Д. Операции с данными в конкретной базе данных и роли, созданной суперпользователем.

 cassandra @ cqlsh> выберите * из system_auth.role_permissions;

Выход: