Безопасный способ аутентификации серверных процессов, которым необходимо подключиться к Oracle - PullRequest
Новая
       27

Безопасный способ аутентификации серверных процессов, которым необходимо подключиться к Oracle

0 голосов
/ 16 марта 2012

Мы используем Oracle 11.2, а серверные процессы, написанные на C ++, выполняются на Solaris 10. У нашего персонала поддержки есть свои собственные имена пользователей Oracle, и у нас есть выделенный пользователь Oracle для наших серверных процессов (назовем его servuser).

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

Очевидным решением этой проблемы будет использование аутентификации ОС - создайте пользователя Solaris для процессов и сопоставьте его с серверу Oracle. Единственная проблема с этим: эти процессы сервера работают на отдельном хосте от экземпляра Oracle. Включение удаленной авторизации - это огромная, хорошо известная дыра в безопасности (просто создайте своего пользователя в своей ОС - presto).

Все остальные стратегии, о которых я могу подумать, бесполезны:

  1. Хранение паролей в файлах в учетной записи Solaris не годится, так как персонал службы поддержки может их видеть и использовать для подключения через sqlplus;

  2. Шифрование файла было бы бесполезным - серверный процесс должен был бы иметь доступ к закрытому ключу, который затем был бы доступен персоналу поддержки, который затем мог бы расшифровать, и мы вернемся к шагу 1.

  3. Я думал о создании триггера входа в систему, который проверяет, подключаемся ли мы как servuser, а затем вызываю исключение, если значения модуля / программы в v $ session не совпадают с тем, что мы определили как действительные клиенты. Это слабая защита, поскольку кто-то может написать свое собственное приложение, которое подделает эти значения.

Каков «официальный» способ обработки этого сценария? Аутентификация ОС работает надежно только в том случае, если вы запускаете свой клиент на той же машине, где находится ваш экземпляр, что кажется довольно бесполезным, IMO. Тем не менее, я думаю, что наш сценарий довольно распространен - ​​серверы приложений работают на отдельном экземпляре, но вы хотите убедиться, что только они могут использовать привилегированную учетную запись.

Предложения

1 Ответ

0 голосов
/ 16 марта 2012

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

Менее идеальным был бы триггер входа в систему, который проверял имя пользователя и IP-адрес клиента и запрещал вход в систему, если соединения исходили с компьютера, отличного от коробки Solaris (возможно, в дополнение к проверке модуля или программы).Обычно это работает, но всегда есть вероятность того, что кто-то подделает свой IP-адрес.Но подделка IP-адреса клиента и создание его похожего на сервер приложений в сети обычно приводит к возникновению проблем с маршрутизацией, поэтому атаку будет относительно трудно осуществить.

...