☰

Как быть с доменами, имена которых не должны публиковаться в соответствии с принципом прозрачности сертификатов?

tag-icon • tag-icon ssl-certificate domain-name
Как быть с доменами, имена которых не должны публиковаться в соответствии с принципом прозрачности сертификатов?

У меня есть набор доменных имен, которые используются внутри компании, и я не хочу, чтобы они стали известны внешнему миру (так как это даст злоумышленнику дополнительные сведения о структуре внутренней сети). УчитываяПрозрачность сертификатаКажется, это набирает обороты, каково общее мнение о лучшем способе иметь частные доменные имена? Самоподписанные сертификаты? Wild card сертификаты? Что-то еще?

решение1

У меня есть набор доменных имен, которые используются внутри компании.

Только для внутреннего использования вы можете создать частный центр сертификации, установить его сертификат во внутренних системах и самостоятельно выпускать внутренние сертификаты.

Если вашвнутреннее использованиесерверы каким-то образом используются извне, они не будут работать, если внешние клиенты не добавят исключение для вашего сертификата. Это не остановит внешних злоумышленников от обнаружения внутренних доменов и атаки на них. В этом случае используйте wildcard-сертификат. Использование самоподписанного или внутреннего сертификата CA будет раздражать внешних пользователей и не сделает ничего, чтобы защитить вас от злоумышленников (как и большинство схем DRM).

решение2

Если утечка имен хостов является частью вашей модели угроз, то CT, вероятно, не единственный источник такой утечки. Подумайте о заголовках электронной почты, журналах, мониторинге, компиляторах, ... множество инструментов могут в конечном итоге выплеснуть системные имена (будь то имена хостов или просто часть сертификатов) в общедоступные пространства. Вместо этого работайте над основными причинами, по которым они должны оставаться конфиденциальными.

Вам не придется их скрывать, если в них нет ничего секретного. Если они раскрывают какую-то информацию, то обычно это происходит потому, что вы используете имена, чтобы

  1. помогите администраторам ориентироваться в вашей сети или
  2. помогите коллегам запомнить, какой URL-адрес вводить.
  3. внутреннее тестирование системы перед коммерческой эксплуатацией

Для всех 3 проблем есть лучшие решения. Основная проблема 1. заключается в том, что системные имена обычно не соответствуют системным ролям после ряда изменений. Основная проблема 2. заключается в том, что ваши коллеги в любом случае не должны вводить URL вручную — подумайте о мошенничестве с доменами с ошибками. Кодовые имена решают 3.

Рекомендация: Присваивайте внутренним серверам имена, используя последовательную, но в остальном случайную схему.Передайте отношения система <> роль с помощью совершенно других средств. Обычно вы обращаетесь к своим коллегам по имени, а не по роли — сделайте это для своих внутренних серверов аналогичным образом.

Наш внутренний wiki размещен на lake.example.org. Lake ничего не значит, он просто достаточно отличается от cube.example.org(коллекции журналов). Но злой злоумышленник знает только о 8 внутренних доменах, что неудивительно для размера организации. Если он хочет узнать больше, ему придется зайти к нам и прочитать теги имен.

решение3

Это кажется довольно простым решением, если я ничего не упускаю.

Если вы считаете, что конфиденциальность данных, которые будут раскрыты посредством прозрачности сертификатов, важнее удобства наличия сертификатов, подписанных общедоступным доверенным центром сертификации, вы можете:

  • Не используйте сертификаты (неразумно и нецелесообразно с современным программным обеспечением)

или

  • Запустите собственный центр сертификации и избавьтесь от неудобств, связанных с настройкой клиентов, которым он должен доверять.

Связанный контент