Комментарии (1)
🐱
claude-haiku-4.5PrepBro AI29 мар. 2026 г.(ред.)
Ответ сгенерирован нейросетью и может содержать ошибки
Что такое Kerberos? System Analyst guide
Краткий ответ
Kerberos = протокол аутентификации для сетей
Это способ безопасно проверить: "Ты точно ты, кто ты говоришь?"
Название
Kerberos - Мифология:
Трёхголовый пёс в древнегреческой мифологии
Охранял врата подземного мира Ада
Символ: "сторож" который проверяет доступ
Альтернативная версия:
KER-BER-OS → три компоненты
1. Client (твой компьютер)
2. KDC - Key Distribution Center (сервер)
3. Server (сервис который ты используешь)
Проблема которую решает Kerberos
У тебя есть 100 серверов в сети
❌ Плохо (без Kerberos):
- Сервер A просит логин/пароль
- Ты передаёшь пароль через сеть
- Кто-то может перехватить пароль (man-in-the-middle)
- Даже если HTTPS, всё равно рисковано
- Когда ты заходишь на сервер B → снова вводишь пароль
- Много мест где пароль может быть украден
✓ Хорошо (с Kerberos):
- Кербер центр (KDC) хранит все пароли
- Ты доказываешь себя KDC один раз
- KDC даёт тебе "票券" (ticket)
- Ты используешь этот ticket со всеми серверами
- Пароль никогда не передаётся по сети!
- Ticket имеет срок действия (например, 8 часов)
Как работает Kerberos (упрощённо)
User (ты) KDC (Sервер) Server (услуга)
| | |
1. Ввод пароля | |
| | |
|--authentication req--------->| |
| (username, no password!) | |
| Verify password |
| | |
|<------TGT returned------| |
| (TGT = Ticket Granting Ticket) |
| (это просто зашифрованный ticket) |
| | |
2. User использует TGT |
| | |
|--service req w/ TGT--------->| |
| ("Я хочу ticket для Server") | |
| Check TGT |
| Generate service ticket |
| | |
|<--service ticket returned----| |
| | |
3. User использует service ticket |
| | |
|--service req w/ ticket--------------------->| |
| | Verify ticket |
| | Grant access |
|<------access granted----------------------| |
| | |
Компоненты Kerberos
1. KDC (Key Distribution Center)
Dва подсервиса:
a) AS (Authentication Server)
- Проверяет username и пароль
- Выдаёт TGT (Ticket Granting Ticket)
- Ты используешь только один раз при логине
b) TGS (Ticket Granting Server)
- Принимает TGT
- Выдаёт service tickets для конкретных сервисов
- Ты используешь каждый раз когда нужен новый service
КДЦ хранит:
- Hash'и паролей всех users
- Ключи всех сервисов
- Все это в базе Kerberos database
2. TGT (Ticket Granting Ticket)
Твой проездной билет в мир Kerberos
Что в нём:
- User ID
- Expiry time (например, 8 часов)
- Session key (key для общения с TGS)
- Зашифровано KDC ключом
Очень важно:
- TGT зашифрован, ты не можешь его изменить
- Только KDC может его создать или проверить
- Даже если хакер украдёт TGT, не поможет (зашифрован)
3. Service Ticket
Удостоверение что ты можешь использовать сервис
Что в нём:
- User ID
- Service ID (например, "host/server.example.com")
- Expiry time
- Session key для общения с сервисом
- Зашифровано key сервиса
Когда ты идёшь к сервису:
- Ты отправляешь service ticket
- Сервис проверяет (расшифровывает своим ключом)
- Если OK → даёт доступ
Полный пример: User логинится на сервер
Условие:
User: alice
Password: secret123
Хочет: SSH на сервер web1.example.com
════════════════════════════════════════════════════════
1️⃣ Alice запускает kinit (или вводит пароль в систему)
$ kinit alice
Password: secret123
Что происходит:
- Alice отправляет KDC(AS):
"I'm alice, authenticate me"
- (пароль НЕ отправляется, только хеш для проверки!)
KDC(AS):
- Берёт пароль alice из базы
- Проверяет хеш
- Если match: создаёт TGT
TGT содержит:
{
user: alice
expiry: 2026-04-15 17:00 (8 hours)
session_key: random123
encrypted_with: KDC_key
}
KDC отправляет alice:
- TGT (зашифрованный)
- Session key (для расшифровки следующих сообщений)
════════════════════════════════════════════════════════
2️⃣ Alice хочет SSH на web1
$ ssh alice@web1.example.com
Что происходит:
- SSH клиент видит TGT в памяти
- SSH говорит KDC(TGS):
"I'm alice (with TGT), give me ticket for web1"
KDC(TGS):
- Проверяет TGT (расшифровывает и смотрит)
- Если TGT valid: создаёт service ticket
Service ticket для web1:
{
user: alice
service: host/web1
session_key: random456
expiry: 1 hour
encrypted_with: web1_key
}
KDC отправляет alice:
- Service ticket
- Session key для общения с web1
════════════════════════════════════════════════════════
3️⃣ Alice подключается к web1 через SSH
Что происходит:
- SSH клиент отправляет web1:
Service ticket + encrypted message
web1:
- Расшифровывает service ticket своим ключом
- Если OK: смотрит внутри
{
user: alice ✓
service: host/web1 ✓
expiry: not expired ✓
}
- Дает alice SSH доступ
- Используют session key для шифрования SSH трафика
════════════════════════════════════════════════════════
4️⃣ Alice хочет доступ к файловому серверу
$ mount //fileserver/share /mnt
Что происходит:
- Linux видит TGT в памяти (всё ещё valid)
- Идёт в KDC(TGS):
"Give me ticket for fileserver service"
- KDC генерирует новый service ticket
- Alice отправляет fileserver service ticket
- fileserver проверяет и дает доступ
⚠️ Важно: Alice НЕ ввела пароль второй раз!
TGT она использует много раз
Преимущества Kerberos
✓ Пароль никогда не передаётся по сети
- Отправляется только хеш для проверки
- Или вообще используются смарт-карты
✓ Single Sign-On (SSO)
- Логинишься один раз
- Используешь TGT для всех сервисов
- Не нужно помнить пароль для каждого
✓ Tickets имеют сроки действия
- Украденный ticket = бесполезен через час
- Автоматическое "выключение" доступа
✓ Взаимная аутентификация
- Сервис доказывает что он настоящий
- User доказывает что он настоящий
- Protection от fake сервисов
✓ Зашифрованная коммуникация
- Session keys используются для шифрования
- Перехват трафика не помогает
✓ Масштабируемость
- Один KDC может обслуживать тысячи клиентов
- Можно реплицировать KDC для redundancy
Недостатки Kerberos
✗ Сложность
- Сложно настроить и поддерживать
- Много компонентов (KDC, TGS, AS)
- Синхронизация часов (нужно NTP)
✗ Требует синхронизацию часов
- Если часы расходятся > 5 мин → tickets invalid
- На практике это частая проблема
✗ Password-based
- Всё равно хранит пароли (хеши)
- Слабый пароль = слабая безопасность
✗ SPNs (Service Principal Names)
- Нужно правильно configurить
- Ошибка конфигурации → доступ не работает
✗ Не работает через интернет (обычно)
- Рассчитан для внутренних сетей
- На интернет используют LDAP + TLS
Real-world использование
Active Directory (Windows)
- Использует Kerberos для аутентификации
- Когда ты логинишься на Windows domain
- Обычно работаешь в корпоративной сети
Linux/Unix
- MIT Kerberos
- Heimdal Kerberos
- SSSD (System Security Services Daemon)
Cloud/Kubernetes
- Может использовать Kerberos через LDAP
- Или более modern методы (OAuth, OIDC)
Big Data
- Hadoop, Spark используют Kerberos
- Для аутентификации в безопасных кластерах
Альтернативы Kerberos
ОДНЕ ВРЕМЕНИ был standard, теперь:
✗ LDAP (Lightweight Directory Access Protocol)
- Directory service, не authentication
- Часто комбинируется с Kerberos
✓ OAuth 2.0 / OpenID Connect
- Современные стандарты для интернета
- Используют token вместо tickets
- Лучше для cloud и web
✓ SAML 2.0
- Enterprise Single Sign-On
- Для больших организаций
- XML-based
✓ Mutual TLS (mTLS)
- Использует сертификаты
- Не требует центрального KDC
- Хорошо для микросервисов
⚠️ Для новых систем обычно выбирают OAuth/OIDC, не Kerberos
Для System Analyst'а
Когда это важно:
-
Enterprise системы
- Если интегрируешься с Active Directory
- Нужно понимать как SSO работает
-
Big Data проекты
- Hadoop, Spark требуют Kerberos
- Нужно спроектировать аутентификацию
-
Безопасность
- Designing secure системы
- Kerberos один из вариантов
-
Миграция
- Moving от legacy Kerberos → modern OAuth
- Нужно понимать обе системы
Вопросы которые ты можешь задать:
- "Как authenticatе users в новой системе?"
- "Нужно ли SSO через Active Directory?"
- "Какие security requirements?"
- "Legacy система ест Kerberos или OAuth?"
Вывод
Kerberos = надёжный способ аутентификации для корпоративных сетей
Clusters (3 компонента):
1. Client (ты)
2. KDC (сервер с паролями)
3. Server (сервис который нужен)
Жизненный цикл:
1. Логин → получить TGT
2. Запрос сервиса → получить service ticket
3. Использовать service ticket → получить доступ
Ключевые преимущества:
- Пароль не передаётся по сети
- Single Sign-On
- Tickets с временем жизни
- Взаимная аутентификация
Результат: Безопасная аутентификация без постоянной передачи пароля
Для System Analyst: Кербер это守门狗инструмент в enterprise security. Нужно понимать basics, когда он нужен, и как его использовать при проектировании secure систем.