Как в корпоративной среде с более чем 1000Linux-устройствами настраиваются политики для авторизации и аутентификации пользователей?

Я начинаю свою новую рубрику вопросов, направленную на понимание структуры корпоративной среды. Предыдущий вопрос касался корпоративного зеркала, а сейчас мне интересно разобраться с вопросом авторизации. 

Предположим, в крупной организации имеется 1000 серверов на базе Linux. Обычно работают системные администраторы, которые отвечают за сервисы, а также администраторы, управляющие операционными системами, их выделением и обслуживанием. Как в такой инфраструктуре настраиваются методы авторизации и аутентификации? Какие учетные записи используются в вашем опыте? Применяете ли вы Red Hat IdM или FreeIPA? Например, случаи, когда доступ к системам необходим временным администраторам, таким как инженеры, достаточно распространены. Создаете ли вы индивидуальные локальные учетные записи для каждого из таких случаев, и насколько корректной является такая политика?

Также хочу уточнить по поводу предыдущего вопроса о корпоративном зеркале и управление пакетами, который остался без ответа. Это вопрос вы можете найти здесь - <a href="https://qna.habr.com/q/1380560" rel="nofollow">Как в вашей компании обеспечивается установка пакетов и обслуживание репозиториев?</a>. Например, для CentOS на 6 версии я загрузил 6.10, для 7 версии — 7.9.2009, а для 8 версии — 8.5.2111. Нужно ли создавать полные репозитории для всех версий? Учитывая, что у каждой версии могут быть различные обновления, скажем, для CentOS 6.0 их около 5 или 6, нужно ли иметь локальное зеркало для каждой из этих версий?
  • 3 декабря 2024 г. 4:23
Ответы на вопрос 2
В крупных корпоративных средах с большим количеством Linux-устройств авторизация и аутентификация пользователей — это ключевые аспекты безопасности и управления доступом. Рассмотрим, как это может быть реализовано.

### Аутентификация и авторизация

1. **Централизованная аутентификация**:
   В большинстве крупных организаций используется централизованное решение для управления аутентификацией и авторизацией. Такое решение может включать:
   - **Red Hat Identity Management (IdM)** или **FreeIPA**: Эти инструменты предоставляют возможность централизованного управления пользователями и группами, использование Kerberos для аутентификации, управление политиками доступа, а также интеграцию с существующими LDAP- или Active Directory (AD) системами.
   - **LDAP-серверы**: Для хранения учетных записей пользователей, групп и атрибутов они могут использоваться совместно с Kerberos.

2. **Управление доступом**:
   - **Групповые политики**: Пользователи могут организовываться по группам, и доступ к системам может быть настроен на уровне групповых политик. Это упрощает управление доступом, особенно когда возникают временные или проектные требования.
   - **sudo и RBAC**: Использование `sudo` для предоставления временного привилегированного доступа пользователям позволяет ограничить действия, которые они могут выполнять. Также могут использоваться механизмы управления доступом на основе ролей (RBAC) для более детального контроля.

3. **Временные учетные записи**:
   - Для временных администраторов, таких как инженеры, обычно не практикуется создание индивидуальных локальных учетных записей. Вместо этого чаще всего используются временные группы или временные привилегии с помощью `sudo`, что позволяет сократить риски собирания учетных записей.
   - Временные учетные записи могут создаваться в случае особых требований, но они должны быть четко задокументированы и контролируемы, чтобы избежать серьезных проблем с безопасностью.

### Управление пакетами и корпоративное зеркало

По поводу вашего вопроса о локальном зеркале и управлении пакетами:

1. **Стратегия управления версиями**:
   - Обычно рекомендуется создать полное локальное зеркало для каждой поддерживаемой версии системы. Это связано с тем, что разные версии могут иметь разные пакеты, их зависимости и обновления. Это поможет избежать проблем с совместимостью.
   - Если у вас есть несколько минорных версий (например, CentOS 6.0 до 6.10), то сокращение количества зеркал до одной версии может привести к тому, что у вас не будет всех необходимых патчей безопасности или функций, которые могут понадобиться.

2. **Локальное зеркало и его поддержка**:
   - Локальное зеркало обеспечивает высокую скорость установки и обновления пакетов в сети компании, экономит трафик и снижает нагрузку на внешние ресурсы.
   - Для версий, которые больше не поддерживаются, можно рассмотреть возможность создания архивных репозиториев, но рекомендуется иметь доступ к последним версиям для обеспечения безопасности и устойчивости систем.

Таким образом, системное администрирование в таких больших компаниях предполагает централизованные подходы к управляющим системам, чтобы упростить администрирование, повысить безопасность и обеспечить простой доступ к ресурсам.
Локальные учётные записи не делаются, всё рулится централизованно через AD/LDAP. Если каким-то внешним подрядчикам нужен админский доступ к определённым хостам - им выдаётся сетевой доступ только к этим хостам и они добавляются в группу, дающую sudo только на этой группе хостов. 

Локальные зеркала не делаются "определённых версий", и не выкачиваются целиком - это бессмысленно, т. к. PCI DSS, например, требует регулярного обновления пакетов. В каком-нибудь Нексусе настраивается проксирование официальных репозиториев с кэшированием пакетов - и вы получаете сразу все поддерживаемые версии и храните только те пакеты, которые используются.
Похожие вопросы