Комментарии 16
А у нас авторизация с помощью RSA ключей…
На сайтах? Круть, а можно пруф на опенсорс проект, который позволяет это делать?
Разве это не как то так www.opennet.ru/base/sec/ssl_cert.txt.html?
Извините, ссылочки нет, так как проект не опенсорс, да и вообще не для широкой публики…
К любой CMS адаптер с авторизацией через RSA пишется за пару часов максимум. Веб-сервер тоже не так долго настроить.
Я вот подумал: а ключи общие или универсальные? А если уволенный сотрудник сопрёт ключ (один из ключей)?
К каждому проекту пароль уникальный. Для админки каждый участник проекта имеет свой аккаунт с уникальным паролем. Для доступа к серверным ресурсам клиента используем единый пароль на команду и знает его только команда проекта. Менеджер проектов знает все пароли, кроме паролей сотрудников от админки.
Хранится все в кейпасе, полный доступ только у руководства (всемогущего админа у нас нет). Общие пароли прописаны в задачах в Мегаплане. Сохранять пароли в FTP-клиенте запрещено — сотня зараженных сайтов более страшный эпик фейл, чем уволенный сотрудник с доступом.
После завершения работы над проектом, аккаунты сотрудников блокируются, а пароль к серверным ресурсам генерируется заново. Если какие-то сайты у нас на постоянной поддержке, то чаще всего создается аккаунт для редактора сайта с ограниченными правами, пароль знает только редактор и менеджер.
Хранится все в кейпасе, полный доступ только у руководства (всемогущего админа у нас нет). Общие пароли прописаны в задачах в Мегаплане. Сохранять пароли в FTP-клиенте запрещено — сотня зараженных сайтов более страшный эпик фейл, чем уволенный сотрудник с доступом.
После завершения работы над проектом, аккаунты сотрудников блокируются, а пароль к серверным ресурсам генерируется заново. Если какие-то сайты у нас на постоянной поддержке, то чаще всего создается аккаунт для редактора сайта с ограниченными правами, пароль знает только редактор и менеджер.
А мне кажется, что делать клиенту кастрированный «административный» интерфейс — это как-то совсем непорядочно. Как, кстати, и оставлять себе доступ к управлению сайтом после того, как проект был сдан и принят.
Частенько клиенты сами этого просят. Видимо пугаются полной админки скажем Drupal, боятся что-то случайно испортить. Ну и зачастую, стадия разработки проекта плавно перетекает в стадию поддержки. Тогда если система разрешает создания двух «рутов», то клиенту вместе с рабочими аккаунтами передаются данные одного с настоятельной рекомендацией ем самому не пользоваться. Если не допускает, то передаются инструкции по сбросу пароля «рута», иногда даже клиенту непонятные, рассчитанные на специалистов (типа «заменить в таблице users для id = 1 значение в поле password_hash на sha1( + ), где — новый пароль, а — параметр в config/security.conf, который нельзя изменять не заставляя всех пользователей сбрасывать пароль»). А если передавать клиенту данные того же аккаунта под которым собираешься поддерживать, то возможны конфликтные ситуации, когда каждая сторона считает, что накосячила другая своими суперправами.
Я вижу одно из решений этой проблемы:
1. Логин под «рутом» может быть произведен только из одного места в один момент времени, для избежания ситуации «зашли оба админа, каждый поменял свое, а сломалось общее — и никто не виноват».
2. Все действия внутри сессии, которые изменяют внутреннее состояние сайта, логгируются с указанием, в какой сессии это происходило.
3. Если возникает вопрос «кто покодил, тот пусть и убирает», то поднимается лог и совместно разглядывается.
1. Логин под «рутом» может быть произведен только из одного места в один момент времени, для избежания ситуации «зашли оба админа, каждый поменял свое, а сломалось общее — и никто не виноват».
2. Все действия внутри сессии, которые изменяют внутреннее состояние сайта, логгируются с указанием, в какой сессии это происходило.
3. Если возникает вопрос «кто покодил, тот пусть и убирает», то поднимается лог и совместно разглядывается.
Мы вобще не практикуем «судийных» аккаунтов на продакшене. Приведите пример когда они жизненно необходимы? ИМХО это потенциальная дыра в безопасности.
Зато уже не первый год упешно используем следующую схему:
— Есть тестовые сайты, доступ к которым закрыт HTTP авторизацией. Для доступа используются логин и пароль от учетки Redmine. Если отключить участника от проекта или заблокировать его учетку (в Redmine), тогда он автоматически потеряет доступ к тестовому сайту.
— Если для разработчикам нужна информация с БД продакшена, тогда тестовая база синхронизируется или автоматически или скриптом (по SSH запросу). «Ручная» синхронизация актуальна для больших БД. Обязательно (!) при переносе данных с продакшена на тестовый удаляем всю конфиденциальную информацию (личные сообщения пользователей, хеши паролей и соль, информацию о заказах и т.д.)
4й год полет нормальный :)
Зато уже не первый год упешно используем следующую схему:
— Есть тестовые сайты, доступ к которым закрыт HTTP авторизацией. Для доступа используются логин и пароль от учетки Redmine. Если отключить участника от проекта или заблокировать его учетку (в Redmine), тогда он автоматически потеряет доступ к тестовому сайту.
— Если для разработчикам нужна информация с БД продакшена, тогда тестовая база синхронизируется или автоматически или скриптом (по SSH запросу). «Ручная» синхронизация актуальна для больших БД. Обязательно (!) при переносе данных с продакшена на тестовый удаляем всю конфиденциальную информацию (личные сообщения пользователей, хеши паролей и соль, информацию о заказах и т.д.)
4й год полет нормальный :)
У меня к каждой админке генерируется бэкдорный пароль (позволяет зайти под админом в обход установленного владельцем сайта пароля), который основывается на текущем времени, домене, ip входящего. В самой админке при авторизации так же проверяется на третьей стороне. Пока все ок.
Бедные, бедные люди. Как хорошо админам с ssh-ключами.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Вы используете универсальный пароль для клиентских сайтов?