Я пытаюсь настроить Amazon DMS для репликации данных из наших производственных экземпляров SQL Server (в настоящее время работающих в выделенных экземплярах EC2) в Redshift для целей хранения данных. Документация DMS прямо заявляет который:
Учетная запись пользователя AWS DMS должна иметь sysAdmin фиксированная роль сервера в базе данных Microsoft SQL Server, к которой вы подключаетесь.
Проверка подлинности Windows не поддерживается.
Это касается нашего администратора базы данных. Они опасаются создавать учетную запись (на самом деле sql или AD) с правами системного администратора, а затем предоставлять этот доступ сторонней службе. Хотя я понимаю эту озабоченность, я склонен доверять Amazon, создавать учетную запись службы и продолжать свой рабочий день.
Они предложили настроить задание для предоставления учетной записи необходимой роли sysAdmin непосредственно перед ночной синхронизацией, а затем отменить разрешения после завершения задания. Мне это кажется излишне параноидальным и совсем не работает, если мы перейдем к непрерывная репликация.
Итак, мой вопрос: насколько опасно создание такой учетной записи (при условии, что соблюдаются другие передовые методы, например: надежно зашифрованные пароли, ограниченный доступ по IP-адресу и т. Д.)? Есть ли веская причина не двигаться вперед, или это просто издержки ведения бизнеса?
Есть ли веская причина не двигаться вперед, или это просто издержки ведения бизнеса?
Я полностью понимаю нежелание администратора базы данных и выдачу SA - не лучшая практика. Это становится особенно грубым, если сервер подпадает под какие-либо отраслевые правила, такие как PCI / SOX, где логины с SA должны контролироваться и иметь обоснование.
Тем не менее, есть бизнес-потребность в этом и вы уже используете AWS, что делает концерн рода спорным. Я бы определенно как Amazon за список разрешений, а не только SA, но я бы также (параллельно) продолжил тестирование и не позволил бы ему быть блокировщиком.
насколько опасно создание такой учетной записи (при условии, что соблюдаются другие передовые методы, например: надежно зашифрованные пароли, ограниченный доступ по IP-адресу и т. д.)?
Предоставление SA не должно быть легким делом, так как любой, у кого есть доступ к нему, может делать все, что угодно, не оставляя следов. Предполагая, что этот сервер не доступен напрямую из Интернета, а вход в систему ограничен IP-адресом и т. Д., Это наилучшим образом ограничит площадь поверхности. После этого нужно доверять Amazon, что не похоже на то, чтобы у вас была причина не доверяйте им.
В целом, я бы попросил список наименьших необходимых разрешений, но продолжил бы использовать службу и настраивать учетную запись по мере необходимости. Лично я бы добавил дополнительный аудит для этого входа в систему и наблюдал за ним, как ястреб, в своей тестовой среде, чтобы увидеть, что он «на самом деле» делает ... но это то, что требуется, если вы хотите использовать услугу - цена ведения бизнеса с этот владелец сервиса.