Удостоверяющий центр открыть: Как открыть удостоверяющий центр — СКБ Контур

Удостоверяющий центр открыть: Как открыть удостоверяющий центр — СКБ Контур

Установка центра сертификации на предприятии. Часть 1 / Блог компании Microsoft / Хабр

Привет, Хабр! Мы начинаем новую серию статей. Она будет посвящена развертыванию службы сертификатов на предприятии на базе Windows Server 2016 с практическими примерами. Сегодня обозначим вступительные моменты и поговорим о типовых схемах развёртывания иерархии PKI: двухуровневой и многоуровневой. Обо всем этом читайте под катом.

Вторая часть серии

Третья часть серии

Введение

Целевая аудитория

ИТ-администраторы, ИТ-инженеры и специалисты по безопасности, имеющие основные понятия о цифровых сертификатах.

Словарь терминов

В этой части серии использованы следующие сокращения и аббревиатуры:

• PKI (Public Key Infrastructure) — инфраструктура открытого ключа (ИОК), набор средств (технических, материальных, людских и т. д.), распределённых служб и компонентов, в совокупности используемых для поддержки криптозадач на основе закрытого и открытого ключей. Поскольку аббревиатура ИОК не является распространённой, здесь и далее будет использоваться более знакомая англоязычная аббревиатура PKI.
• X.509 — стандарт ITU-T для инфраструктуры открытого ключа и инфраструктуры управления привилегиями.
• ЦС (Центр Сертификации) — служба, выпускающая цифровые сертификаты. Сертификат — это электронный документ, подтверждающий принадлежность открытого ключа владельцу.
• CRL (Certificate Revocation List ) — список отзыва сертификатов. Подписанный электронный документ, публикуемый ЦС и содержащий список отозванных сертификатов, действие которых прекращено по внешним причинам. Для каждого отозванного сертификата указывается его серийный номер, дата и время отзыва, а также причина отзыва (необязательно). Приложения могут использовать CRL для подтверждения того, что предъявленный сертификат является действительным и не отозван издателем.
• SSL (Secure Sockets Layer) или TLS (Transport Layer Security) — технология, обеспечивающая безопасность передачи данных между клиентом и сервером поверх открытых сетей.
• HTTPS (HTTP/Secure) — защищённый HTTP, являющийся частным случаем использования SSL.
• Internet PKI — набор стандартов, соглашений, процедур и практик, которые обеспечивают единый (унифицированный) механизм защиты передачи данных на основе стандарта X.509 по открытым каналам передачи данных.

Зачем нужен частный PKI?

Шифрование, цифровые подписи и сертификаты всё плотнее входят в нашу повседневную интернет-жизнь. Если об этих терминах 10 лет назад говорили мало, и далеко не всем ИТ специалистам был известен смысл этих слов, то сейчас они у многих на слуху. И этот процесс длится не год и не два, а добрый десяток лет. Сейчас мы находимся в активной фазе развития клиент-серверных веб-сервисов (привет мейнфреймам!), и значительная доля коммуникации людей и устройств перекладывается на компьютерные сети и интернет. Как следствие, новые условия диктуют новые требования к защите данных. Крупные производители ПО активно продвигают идеологию «безопасного интернета», требуя поддержки цифровых сертификатов, начиная от серверов с конфиденциальными данными, облачных служб, вплоть до кухонного чайника или бельевого утюга (IoT).

Некоторые компании делают это весьма настойчиво. Так, начиная с 2017 года, компания Google считает все сайты без поддержки HTTPS небезопасными: Moving towards a more secure web. И это весьма ощутимо влияет на интернет-индустрию. Во-первых, предупреждение в браузере (Google Chrome) явно не будет радовать ваших потенциальных клиентов и просто посетителей. Во-вторых, сайты без поддержки HTTPS опускаются в поисковой выдаче. Mozilla и другие крупные вендоры также не отстают от Google: Deprecating Non-Secure HTTP. С одной стороны, компании давят на интернет-индустрию, толкая организации на дополнительные расходы, связанные с цифровыми сертификатами. С другой стороны, это — вынужденный шаг, и всем нужно идти в ногу со временем.

Однако текущее положение Internet PKI не позволяет решать эти вопросы достаточно гибко и удобно, требуя существенных затрат. Например, один сертификат SSL для публичного веб-сервера вам обойдётся в сумму порядка $100, а если хотите сертификат с зелёной полосой, это вам будет стоить ещё дороже. И это только за один сертификат! При этом автоматизация процессов находится в самом зачаточном состоянии.

Для решения этих проблем крупнейшие вендоры ПО объединились и совместными усилиями наводят порядок с цифровыми сертификатами в Internet PKI. Во-первых, создан единый стандартизирующий орган — CAB Forum (CA/Browser Forum), который определяет стандартные практики для коммерческих CA, производителей веб-ПО и потребителей сертификатов. Во-вторых, активное продвижение некоммерческого CA (но глобально доверенного) Let’s Encrypt для обеспечения бесплатными сертификатами с возможностью автоматического продления.

Казалось бы, это решает все проблемы безопасной коммуникации, и частные PKI (разворачиваемые в пределах организации) стали сразу ненужными. В какой-то, да, если частный PKI занимался обслуживанием внешних серверов (веб, VPN и т.д.). Но сервисы наподобие Let’s Encrypt в настоящее время покрывают лишь узкий спектр корпоративных потребностей в сертификатах. Например, не покрываются сертификаты для шифрования документов, почты, цифровых подписей. Часть задач, как аутентификация клиентов не покрывается совсем. Ещё одним ограничением является то, что для использования публичных сертификатов, выданных коммерческими CA вам необходимо иметь публичный домен. Получить сертификат для веб-сервера на имя domain.local от Let’s Encrypt технически невозможно. Именно поэтому актуальность частных PKI остаётся на очень высоком уровне. Пример использования частных PKI в корпоративной среде изображён на следующем рисунке:

Если компания решает использовать частный PKI в пределах организации, встаёт другой насущный вопрос: как же правильно его организовать, чтобы он отвечал современным практикам и стандартам хотя бы в пределах организации. В интернете можно найти многочисленные статьи о том, как развернуть PKI в компании на основе Active Directory Certificate Services (ADCS). Но в большинстве своём они изобилуют ошибками, исходят из неверных предпосылок и нередко являются копированием какого-то исходного (не всегда удачного) материала, а к имеющимся фундаментальным ошибкам привносят ещё и свои. Как следствие, многочисленные провалы в развёртывании PKI. Об этом можно судить по количеству соответствующих тем на форумах (в частности, TechNet Server Security). Качественной документации на английском языке не хватает, а на русском… Этот цикл статей призван восполнить этот пробел и систематизировать современные наработки.

 

Общие положения

PKI является технологией безопасности, которая основывается на стандарте X.509 и использует цифровые сертификаты. Целью PKI является повышение безопасности ИТ инфраструктуры предприятия за счёт предоставления механизмов по защите данных от несанкционированного доступа и незаконного изменения данных (подделка данных). Это достигается двумя основными криптографическими механизмами:

• Шифрование – защищает данные от несанкционированного доступа третьих лиц путём шифрования данных криптографическими ключами. Только пользователи, имеющие необходимые ключи, могут получить доступ к данным. Шифрование обеспечивает секретность данных, но не защищает от их подмены.
• Цифровая подпись – защищает данные от несанкционированного изменения или подделки путём применения к данным специальных алгоритмов, которые образуют цифровую подпись. Любые манипуляции по изменению данных будут немедленно обнаружены при проверке цифровой подписи. Цифровая подпись обеспечивает не конфиденциальность данных, а их целостность. Путём комбинирования шифрования и цифровой подписи можно организовать обеспечение конфиденциальности и защиты данных от несанкционированных изменений.

Типичная инфраструктура PKI состоит из следующих компонентов:

• Центр Сертификации (ЦС) – служба, предоставляющая цифровые сертификаты потребителям и обеспечивающая функционирование PKI.
• Сервер отзыва – служба, предоставляющая информацию о списках отозванных (скомпрометированных или недействительных) сертификатов, выпущенных конкретным ЦС.
• Клиент – получатель заверенного цифрового сертификата от центра сертификации. Клиентами могут выступать люди, устройства, программное обеспечение, а также другие ЦС.

Структура ЦС и сертификатов выстраиваются в древовидную иерархию. Каждый ЦС может выполнять одну или несколько (совмещать) ролей:

• Корневой ЦС – специальный тип ЦС, который имеет самоподписанный сертификат и является корнем дерева (отсюда и название). Этот тип ЦС является стартовой точкой доверия ко всем сертификатам в данной иерархии (дерева). Иными словами, клиент должен явно доверять конкретному корневому сертификату (а именно, комбинации: издатель и открытый ключ), чтобы доверять сертификатам, находящимся в остальной части дерева. Важно отметить, что доверие транзитивно. Клиент при проверке конечного сертификата будет выстраивать цепочку (путь) от конечного сертификата до вершины иерархии (корневого сертификата). И если клиент доверяет вершине, то будут и основания доверять конечному сертификату на правах транзитивности.
• ЦС политик – технически, это такой же ЦС, как и все остальные (в разрезе иерархии), с тем отличием, что дополняется внешними политиками и ограничениями по выдаче и использования цифровых сертификатов.
• Издающий ЦС – это ЦС общего назначения, который выполняет подпись и выдачу цифровых сертификатов потребителям.

Для понимания процесса построения цепочек сертификатов рекомендую прочитать следующую статью: Certificate Chaining Engine — how it works. Данная статья ориентирована на платформу Microsoft CryptoAPI, она также справедлива (за некоторыми исключениями) и для других реализаций криптографических платформ.

Поскольку ЦС выстраиваются в древовидную иерархию, возможно организовать многоуровневую иерархию, где на каждом уровне ЦС будет выполнять как роль издающего ЦС, так и дополнительные функции. В самом простом случае один ЦС может совмещать все роли, т.е. быть корневым, обеспечивать какие-то политики выдачи и выдавать сертификаты конечным потребителям. Более крупные компании и/или с более зрелой организацией ИТ-процессов уже используют разделение ЦС по ролям. Например, в головном офисе держат корневой ЦС, выдающий сертификаты только другим ЦС, которые уже на себе накладывают политики выдачи. Они могут не обслуживать напрямую конечных потребителей, а выдавать сертификаты другим подчинённым ЦС, которые, в свою очередь, и будут обслуживать конечных потребителей. В каждом подходе есть свои плюсы и минусы, которые будут рассмотрены ниже.

Отзыв сертификатов

Помимо задач по выпуску сертификатов, каждый ЦС периодически выпускает списки отзыва (Certificate Revocation List, CRL). Как и сертификаты, целостность списков отзыва обеспечивается цифровой подписью. CRL содержит серийные номера сертификатов, действие которых прекращено по какой-либо причине до официального истечения срока действия сертификата. Таким образом ЦС обеспечивает своевременное изъятие недействительного сертификата из оборота.

Каждый клиент после установки доверия сертификата через цепочку должен убедиться, что ни один сертификат в цепочке не был отозван своим издателем. Для этого клиент перебирает каждый сертификат в цепочке, выбирает CRL предоставленный издателем и проверяет наличие/отсутствие текущего сертификата в списке CRL. Если текущий сертификат находится в CRL, то доверие к сертификату (и всем ветвям дерева под ним) автоматически обрывается.

Фактически, если корневой ЦС отозвал все свои непосредственно изданные сертификаты, то ни один сертификат под этим корнем не будет доверенным вне зависимости от высоты иерархии. Здесь следует отметить один крайне важный и принципиальный момент: невозможно отозвать корневой (самоподписанный) сертификат. Т.е. если по какой-то причине он был скомпрометирован, его можно отозвать только принудительным удалением сертификата из хранилища сертификатов каждого клиента. Дело в том, что ЦС не определяет списки отзывов для самого себя, это делает издатель. В случае самоподписанного сертификата, ЦС является издателем самого себя. И при попытке включить себя в свой же список отзыва получается неопределённость: сертификат ЦС включен в CRL, который подписан ключом этого же ЦС. Если предположить, что сертификат ЦС недействителен, то и цифровая подпись на CRL является недействительной. Как следствие, невозможно достоверно утверждать, что сертификат корневого ЦС отозван. Причём, отзыв корневых сертификатов не предусмотрен и основным регламентирующим стандартом, RFC 5280, параграф §6.1 которого гласит:

When the trust anchor is provided in the form of a self-signed certificate, this self-signed certificate is not included as part of the prospective certification path.

А на отзыв проверяется только проспективная цепочка. Если говорить в контексте Microsoft ADCS, то тут ситуация усугубляется ещё больше. В частности, вы технически можете отозвать корневой сертификат при помощи certutil.exe или CryptoAPI. Но как только вы это сделаете, ЦС не сможет подписать ни один CRL, как следствие, сертификат ЦС никогда не попадёт в CRL. Более того, даже если использовать различные утилиты (тот же certutil.exe), можно насильно включить сертификат ЦС в CRL, но это мало чем поможет. Дело в том, что конфигурация по умолчанию CryptoAPI даже не пытается проверить корневой сертификат на отзыв.

Проблема отзыва корневых сертификатов во многих случаях будет одним из решающих факторов в выборе подходящей для компании иерархии ЦС. А также будет диктовать дополнительные меры безопасности для корневых ЦС, чтобы предельно снизить риск компрометации корневого ЦС.

Типовые схемы развёртывания иерархии PKI

В этом разделе мы рассмотрим типовые (или классические) схемы развёртывания иерархии PKI в условиях предприятия и проводятся оценки каждой схемы и рекомендации. Следует отметить, что ни одна из них не является универсальной, и каждая может иметь смысл в своих пределах.

Одноуровневая иерархия

Одноуровневая иерархия является самой простой в реализации и имеет следующий вид:

Такая иерархия является самой простой и экономичной как по ресурсам (лицензиям), так и по расходам на обслуживание и управление. Достаточно развернуть один такой ЦС в лесу Active Directory, и он будет обеспечивать сертификатами всех потребителей. Из неочевидных, но немаловажных достоинств можно отметить очень короткую цепочку сертификатов. Т.е. время на проверку доверенности и отзыва сертификата будет тратиться гораздо меньше, чем в любых других иерархиях.

Однако одноуровневая иерархия обладает рядом достаточно существенных недостатков. Самый крупный из них – низкий уровень безопасности. Поскольку ЦС в такой схеме должен быть постоянно включенным в сеть, чтобы клиенты могли запрашивать сертификаты, значительно увеличивается риск его компрометации. Последствия компрометации могут быть чудовищными, вплоть до полной потери контроля над Active Directory и краху ИТ систем. Это может быть вызвано как недостаточными мерами безопасности, наличием не закрытых уязвимостей ОС или компонентах системы, которые позволяют удалённое исполнение кода и т.д. Как отмечалось выше, отозвать нормальным способом такой сертификат уже нельзя, и последствия будут действительно тяжёлыми.

Другой момент связан с гибкостью разделения ЦС на функциональные уровни (делегирование). Например, невозможно организовать несколько различных политик выдачи, разделить на классы (например, один ЦС издаёт сертификаты только машинам и устройствам, другой только для пользователей) и т.д., потому что он всего один.

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

Двухуровневая иерархия

Двухуровневая иерархия уже подразумевает как минимум два ЦС в дереве, в котором один строго корневой, а остальные — подчинённые. Схема такой иерархии представлена ниже:

Примечание: здесь пунктирными линиями отмечен ручной (неавтоматизированный) процесс получения сертификата. Сплошными линиями отмечен автоматизированный процесс получения сертификатов.

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

Другим достоинством двухуровневой иерархии является улучшенная гибкость в разбиении подчинённых ЦС на какие-то классы. Тот же типичный сценарий, когда два ЦС управляются разными подразделениями ИТ, и каждый ЦС выпускает сертификаты для своих групп потребителей. Например, для машин отдельно, для пользователей отдельно. Можно для корпоративных разработчиков (которые обычно живут в своих средах) выделить свой подчинённый ЦС.

Именно здесь уже можно начинать задумываться о разделении ЦС по политикам выдачи (или классам). Например, можно выделить один ЦС для выдачи сертификатов с повышенными требованиями к сертификатам (например, сертификаты для аутентификации и цифровой подписи) и ЦС общего назначения. Управлять ими могут различные команды ИТ-администраторов. При этом каждый подчинённый ЦС будет совмещать задачи ЦС политики и издающего ЦС. Это вполне допустимо, если предположить, что количество ЦС на каждый класс не более одного.

Из недостатков можно выделить лишь некоторое увеличение как административных, так и финансовых издержек (требуется дополнительная лицензия). К административным издержкам добавятся контроль за сроком действия каждого ЦС и списка отзыва корневого ЦС, а также их своевременное обновление. Кроме того, несколько увеличится время построения и проверки цепочек сертификатов, поскольку добавляется ещё один уровень. На практике это время практически не ощутимо.

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

Трёх- и более уровневые иерархии

В более крупных компаниях со сложной организацией сетей может случиться, что двухуровневая иерархия не может обеспечить необходимый уровень гибкости управления ЦС. Например, когда компания использует географический принцип разделения с относительной автономией ИТ отделов в каждом регионе. Представьте международную компанию с региональными офисами в разных странах. В них может действовать своё законодательство в вопросах безопасности, например, при обработке персональных данных. Для соблюдения подобных юридических формальностей на каждый такой регион выделяется свой собственный ЦС политик (при этом, размещается он, как правило, в головном офисе компании). В в своём сертификате он указывает поддержку (и ссылку на соответствующий документ) тех или иных нормативных документов и выпускает сертификаты для издающих ЦС, действующих в рамках тех политик, которые обозначены в сертификате (грубо говоря, в данном регионе).

В таких иерархиях корневой ЦС и ЦС политик изолируют от сети, а к сети уже подключаются только издающие ЦС:

Здесь также пунктиром отмечен ручной процесс получения сертификата для ЦС и сплошными линиями автоматизированный процесс получения сертификата для клиентов.

К плюсам такой схемы можно отнести гибкость полученной PKI с возможностью адаптации под практически любые условия. Правда, за это придётся платить. Во-первых, многоуровневые иерархии удорожают стоимость развёртывания и сопровождения PKI. Во-вторых, клиентам требуется больше времени на построение и проверки на отзыв полных цепочек сертификатов, что может вызывать отказы из-за превышения таймаутов верхних протоколов передачи данных. И на практике такие схемы зачастую являются избыточными. Поэтому при выборе подходящей иерархии ЦС следует искать баланс между гибкостью и практической целесообразностью с учётом капитальных и операционных затрат на содержание PKI.

В рамках этой серии статей рассматривается наиболее популярная (в большинстве случаев) двухуровневая иерархия.

Об авторе

Вадим Поданс — специалист в области автоматизации PowerShell и Public Key Infrastructure, Microsoft MVP: Cloud and Datacenter Management с 2009 года и автор модуля PowerShell PKI. На протяжении 9 лет в своём блоге освещает различные вопросы эксплуатации и автоматизации PKI на предприятии. Статьи Вадима о PKI и PowerShell можно найти на его сайте.

Зачем нужен собственный удостоверяющий центр / Блог компании GlobalSign / Хабр

Примеры 1) промежуточного УЦ в открытой иерархии доверия и 2) частной иерархии, которая изолирована от открытой иерархии, со своим собственным корневым УЦ

Инфраструктура открытых ключей (PKI) традиционно имеет иерархическую структуру. В ней удостоверяющие центры (УЦ) связаны отношениями подчинённости. Все пользователи доверяют одному и тому же корневому (головному) УЦ, а каждый нижестоящий УЦ подчиняется более высокому в иерархии.

Но что, если мы хотим создать частную инфраструктуру PKI со своим собственным УЦ? Действительно, в некоторых ситуациях такие промежуточные или частные иерархии очень удобны на практике.

Типичные причины для создания промежуточной или частной иерархии

• Аутентификация клиентов

  Аутентификацию клиентов по сертификатам удобно сделать на основе промежуточного УЦ. При наличии эксклюзивного подчинённого УЦ можно ограничить число сертификатов, предоставляющих доступ к системе. В этих случаях обычно используются приватные иерархии доверия.
  

• Брендинг

  Для компаний, которые предлагают сертификаты своим клиентам или включают их в комплект оказываемых услуг, наличие своего выделенного УЦ позволяет предложить некоторые дополнительные возможности брендинга.
  

• Инспекция/дешифрование SSL/TLS

  Чтобы устройство проверки SSL могло дешифровать и заново шифровать контент, у него должна быть возможность выдавать сертификаты по мере необходимости. Это означает, что нужен собственный подчинённый УЦ вне публичной иерархии доверия. В этом случае корневой УЦ размещается у GlobalSign, а промежуточный УЦ — на устройстве проверки сертификатов у клиента.
  

• Сертификаты специального назачения

  Сертификаты, выданные в рамках приватных иерархий, могут поддерживать устаревшие приложения и уникальные конфигурации, такие как более длительные периоды действия и меньшие размеры ключей, которые не разрешены в общедоступных доверенных сертификатах по базовым требованиям CA/Browser Forum. Впрочем, если нужны только приватные сертификаты SSL/TLS, без полноценного собственного УЦ, то можно воспользоваться услугой IntranetSSL.
  

• Настраиваемые профили

  Вы можете настроить подчинённый УЦ на конкретные задачи, изменив под свои потребности политики расширенного использования ключей, политики сертификатов, точки распространения списков отзыва сертификатов (CRL), сделав краткосрочные сертификаты и др.

Размещение и поддержка

Хостинг и сопровождение собственного УЦ компания может осуществлять самостоятельно или отдать на аутсорсинг. Многие компании берутся за развёртывание крупномасштабных систем PKI своими силами (инсорсинг), не имея необходимых ресурсов на это. Поскольку процесс требует капиталовложений, то лучше заранее оценить свои материальные ресурсы и финансовые возможности на настоящий момент и в ближайшие годы, экономический эффект от использования новой технологии, начальных затрат и стоимости функционирования системы.

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

Промежуточная или частная иерархия

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

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

В случае частной иерархии конечный пользователь вручную добавляет открытый ключ корпоративного корневого УЦ в список доверенных ключей, встроенных в приложение. В этом случае вся ответственность за использование ключа ложится на самого пользователя. Частные иерархии больше подходят для закрытых сообществ, например, пользователей корпоративного портала.

Типичные примеры промежуточной или частной иерархии

• Выделенный частный корневой УЦ и иерархия (Private PKI)
  GlobalSign может создавать и размещать частные иерархии, включая корневые и промежуточные. Они построены на той же защищённой инфраструктуре, которая используется для поддержки собственных корневых УЦ в открытой иерархии.
  
• Фирменный частный промежуточный УЦ, центр выдачи сертификатов
  Брендовые промежуточные УЦ создаются специально для конкретного клиента, с цепочкой доверия до корневого УЦ в открытой иерархии. Эти промежуточные узлы тоже могут размещаться и поддерживаться GlobalSign, что облегчает бремя управления PKI и экспертных знаний для внутренних команд.
  
• Общий открытый корневой УЦ (платформа Managed PKI)
  Хотя в определённых ситуациях требуются выделенные корневые УЦ и иерархии, большинство организаций может выполнить нормативные требования к сертификатам с помощью специализированных сервисов на платформе управления PKI (Managed PKI). Портал для управления сертификатами «всё в одном» обеспечивает расширенные возможностями выставления счетов, управления пользователями, отчетность и т. д.
  
• Общий частный корневой УЦ (IntranetSSL)
  Решение IntranetSSL, доступное через платформу управления PKI, обеспечивает экономичный способ выдачи и управления сертификатами SSL/TLS для внутренних серверов и приложений. Эти сертификаты выдаются от общего, непубличного Центра сертификации GlobalSign, поэтому могут включать конфигурации, которые форум CA/Browser запрещает использовать в публичных сертификатах (например, срок действия более трёх лет, внутренние имена серверов или зарезервированные IP-адреса).
  
• Корень доверия IoT
  Корни доверия IoT обладают той же гибкостью, что и традиционные корни доверия, но настроены на специфические требования IoT. Выделенные частные иерархии, фирменные общедоступные промежуточные УЦ, корневые центры в открытой или частной иерархии могут использоваться для защиты устройств, платформ, шлюзов и сетей IoT в зависимости от требуемого уровня доверия.
  
• Особенная иерархия доверия
  GlobalSign поддерживает практически любую конфигурацию иерархии. Если нужна модель, отличная от описанной выше, или сразу не совсем понятно, какая архитектура лучше всего подходит для специфической экосистемы, то это лучше обсудить со специалистом и консультантом, чтобы построить архитектуру доверия, которая соответствует конкретным потребностям.

Для любого из приведённых примеров сопровождение УЦ можно отдать на аутсорсинг. Сохраняется возможность брендирования, но иерархии размещаются и управляются GlobalSign в безопасных центрах обработки данных с проверенным оборудованием и программным обеспечением. С нестандартными сценариями помогут справиться инженеры сопровождения.

Кажется, что отдавая свою иерархию доверия на аутсорсинг, вы понижаете уровень безопасности, но на практике выходит наоборот. Это гарантирует, что все компоненты УЦ должным образом защищены и настроены в соответствии с последними передовыми отраслевыми практиками. Дополнительное преимущество — экономия затрат и ресурсной нагрузки на внутренние команды для поддержки PKI. Только в некоторых редких случаях (например, проверка/дешифрование SSL) промежуточное звено должно размещаться у клиента.

---

Удостоверяющий центр — зачем, как и где получать средства ЭЦП

Современный электронный документооборот (далее — ЭДО) практически невозможен без применения электронно-цифровых подписей. Использование этого инструмента необходимо для верификации авторства и определения целостности цифрового документа. Успешное прохождение проверки гарантирует его неотказуемость (non-repudation) — невозможность отчуждения авторства его составителя.

Аппаратно-программные средства для генерации и верификации ЭЦП предоставляются удостоверяющими центрами (далее — УЦ). Считается, что эти организации — цифровые посредники между участниками ЭДО, осуществляющими сетевое онлайн-взаимодействие. Честность и прозрачность работы аккредитованных центров сертификации неоспоримы.

Какие  функции выполняют УЦ? На чем основываются принципы их работы? В статье мы ответим на эти и многие другие вопросы: расскажем, можно ли создать центр сертификации для обеспечения собственных нужд и как это сделать. Вы узнаете, как правильно выбрать сторонний УЦ, почему так важно, чтобы он был аккредитован, лицензирует ли ФСБ РФ деятельность УЦ.

Оформим ЭЦП за один день без вашего участия!

Оставьте заявку и получите консультацию в течение 5 минут.

Получение средства ЭЦП: что такое удостоверяющие центры и для чего они нужны

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

Секретный ключ — набор символов, его длина составляет 256 бит. Хранить его надлежит на носителе, недоступном для третьих лиц (USB-токене, смарт-карте). Секретный ключ необходим для генерации его держателем уникальной ЦП и полной расшифровки получателем, например, сотрудником ФНС РФ, цифрового документа отправителя. Работает он только в тандеме с публичным.

Публичный ключ — шифр (как правило, сложная математическая формула) длиной 1024 бита. Нужен для верификации ЭП, которыми визируются цифровые документы участников ЭДО. На открытый ключ проверки ЭП выдается соответствующий сертификат (далее — СКПЭП). Публичный ключ работает только в тандеме с секретным.

Участники ЭДО обязаны обеспечить наличие своих публичных ключей у каждого коммуниканта, с которым они предполагают обмениваться цифровыми документами, визированными ЦП и упакованными в файлы. Дубликаты публичных ключей хранятся в УЦ. Удостоверяющие центры создают библиотеки (реестры) публичных ключей — таким образом осуществляются регистрация и хранение средств ЭЦП, чтобы избежать их подделок и/или искажений.

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

Средства ЭП, как и саму электро

Что такое удостоверяющий центр? | Какие виды ЭЦП выдает УЦ? — Удостоверяющий центр СКБ Контур

Чтобы получить неквалифицированный и квалифицированный сертификат электронной подписи, необходимо обратиться в один из удостоверяющих центров. Какие функции выполняют удостоверяющие центры и сколько времени займет получение сертификата?

Удостоверяющий центр (УЦ) – доверенная организация, которая имеет право выпускать сертификаты электронной подписи юридическим и физическим лицам. Работа УЦ лежит на пересечении юриспруденции, информационной безопасности и IT-технологий.

В обязанности УЦ входят следующее:

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

Какие виды подписей выдает УЦ?

Законом «Об электронной подписи» определены три вида подписи:

Получать в УЦ необходимо последние две:

• за квалифицированной подписью нужно обращаться только в аккредитованный Минкомсвязью РФ удостоверяющий центр.
• за неквалифицированной — в УЦ, который связан с той информационной системой, где планируется применять подпись. Например, выдавать неквалифицированные сертификаты для торгов могут только УЦ, аккредитованные шестью федеральными электронными торговыми площадками. При этом УЦ может и не быть аккредитован в Минкомсвязи.

Требования к УЦ

От корректной работы УЦ зависит доверие ко всем сферам бизнеса, где применяются электронные подписи: электронные торги, информационные системы, отчетности. Поэтому ко всем УЦ накладываются серьезные технические и юридические требования.

Существует ряд показателей, по которым можно оценить удостоверяющий центр. Надежный УЦ:

• аккредитован Минкомсвязи РФ,
• является доверенным центром ФНС, ПФР, Росстата,
• имеет лицензию ФСТЭК на деятельность по технической защите конфиденциальной информации,
• лицензию Центра по лицензированию, сертификации и защите государственной тайны ФСБ России,
• аккредитован на всех электронных торговых площадках госзакупок,
• долго работает
• имеет представителей в различных регионах России
• оказывает круглосуточную техподдержку

Сколько времени занимает получение сертификата подписи?

Сроки выпуска сертификата зависят от обеих сторон:

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

В среднем получение сертификата занимает 1 рабочий день. В УЦ СКБ Контур есть услуга по срочному выпуску электронной подписи за 1 час после получения нужных документов. 

Удостоверяющие центры электронной подписи: список 2020

Автор: Юдина Ольга 21 октября 2019

Удостоверяющий центр электронной подписи — это юридическое лицо, индивидуальный предприниматель или госорган или орган местного самоуправления, который создает и выдает сертификаты ключей проверки ЭЦП и выполняет другие функции, предусмотренные Федеральным законом № 63-ФЗ от 06.04.2011.

Цели и задачи удостоверяющего центра

Удостоверяющий центр ЭЦП является организацией с функциями администратора по выдаче сертификата ключа на основании ст. 13 закона «Об электронной подписи» (№ 63-ФЗ от 06.04.2011). Он создает сертификаты ключей проверки ЭЦП, устанавливает для них сроки действия и аннулирует их и ведет реестр выданных и аннулированных неквалифицированных сертификатов.

К ним поступают обращения для получения ЭЦП. Они уполномочены устанавливать личность заявителя (получателя ЭП) либо лица, которое выступает от его имени.

Встречаются случаи употребления названия: удостоверяющий центр ЭЦП. Это связано тем, что ранее действовал № 1-ФЗ «Об электронной цифровой подписи». С 1 января 2014 года окончательно вступил в силу № 63-ФЗ, и термин «электронная подпись» полностью заменил «электронную цифровую подпись». Хотя по сей день употребляют оба.

Порядок реализации своих полномочий УЦ устанавливает самостоятельно. Этот порядок существует в виде Регламента. Он содержит и права, и обязанности. Законом установлена ответственность за вред, причиненный третьим лицам, при условии неисполнения или ненадлежащего исполнения обязательств:

• договоры оказания услуг;
• обязанностей.

Аккредитованный удостоверяющий центр

УЦ может пройти и получить аккредитацию. В этом случае он представляет собой аккредитованный центр выдачи электронных подписей.

Он проводит мероприятия по хранению большого объема информации о подготовке и выдаче квалифицированного сертификата. Хранение информации проходит в условиях проверки целостности и достоверности данных.

Под аккредитацией центра понимается его соответствие требованиям 63-ФЗ и разрешение передавать квалифицированные сертификаты. В ч. 3 ст. 16 закона об электронной подписи указано, что удостоверяющие ц

Новости компании

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

Цифровые сертификаты составляют основу технологий работы инфраструктуры открытых ключей (PKI). Данные технологии широко применяются для:

• шифрования сообщений электронной почты,
• электронной подписи документов,
• доступа к VPN сетям,
• серверной SSL аутентификации,
• цифровой подписи исполняемого программного кода и т.д.

Сертификаты – значимая составляющая в стратегии обеспечения безопасности на основе использования PKI, т.к. именно они позволяют установить владельца того или иного открытого ключа.

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

Сертификаты, как правило, выдаются Удостоверяющими Центрами (УЦ или Центр сертификации), являющимися третьей доверительной стороной при передаче информации. УЦ обладают корневыми сертификатами (сертификаты, содержащие их открытые ключи), поставляемые в комплекте с популярными браузерами. УЦ обеспечивают достоверность выдаваемых ими сертификатов за счет добавления в них подписи, созданной на закрытом ключе УЦ. Т.к. каждый браузер обладает открытым криптографическим ключом УЦ, он может подтвердить, что сертификат действительно прислан УЦ.

Следующий этап – вопрос доверия: насколько Вы доверяете репутации УЦ и уверены ли, что утвержденное УЦ действительно достоверно?

Такие УЦ, как VeriSign, например, пользуются хорошей репутацией и их услуги соответствующим образом оплачиваются. Подобные центры запрашивают цену за сертификат в зависимости от длины ключа и из расчета среднего количества издержек, требуемых для процедуры проверки информации о владельце. Например, стандартный годовой сертификат VeriSign стоит 399$, тогда как стоимость сертификата Extended Validation, подразумевающего более детальную проверку информации о владельце, составляет 1499$ в год.

Но если Ваш веб-сервер достаточно безопасен и используется сотрудниками только Вашей организации, либо зашифрованные сообщения адресованы лишь Вашим работникам или Вы используете цифровые сертификаты для идентификации Ваших сотрудников в VPN-сетях, тогда нет необходимости оплачивать работу УЦ.

Ваша организация может функционировать как самостоятельный УЦ и выпускать собственные цифровые сертификаты в целях корпоративного пользования.

Преимущество создания собственного УЦ очевидно – наличие неограниченного количества бесплатных сертификатов. Однако, необходимо будет оплатить лицензию на использование пакета программ УЦ или же развернуть УЦ на бесплатном openssl и покрыть стоимость аппаратного обеспечения.

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

Итак, что происходит, когда сотрудник получает сертификат, выданный Вашей компанией? Как правило, появляются предупреждения системы безопасности, потому как сертификат представлен не одним из доверенных УЦ, чьи корневые сертификаты установлены в на его рабочем месте ранее. Во избежание подобных предупреждений, Вам необходимо установить корневой сертификат организации на используемые Вашими сотрудниками рабочие места. Единственное, о чем не следует забывать — не устанавливать сертификаты организации за ее пределами. Сертификаты Вашей компании будут полезны лишь для использования в корпоративной сети.

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

Источник: www.esecurityplanet.com

Удостоверяющий центр – что это и зачем? | Москва

Удостоверяющий центр – что это и зачем? | Москва | Компания Тензор Используя официальный сайт tensor.ru, вы даете согласие на работу с cookie, Яндекс.Метрикой, Google Analytics для сбора технических данных. Подробнее



• 77 Москва
• 78 Санкт-Петербург
• 01 Республика Адыгея
• 02 Республика Башкортостан
• 03 Республика Бурятия
• 04 Республика Алтай
• 05 Республика Дагестан
• 06 Республика Ингушетия
• 07 Респ. Кабардино-Балкария
• 08 Республика Калмыкия
• 09 Респ. Карачаево-Черкессия
• 10 Республика Карелия
• 11 Республика Коми
• 12 Республика Марий Эл
• 13 Республика Мордовия
• 14 Республика Саха (Якутия)
• 15 Северная Осетия — Алания
• 16 Республика Татарстан
• 17 Республика Тыва
• 18 Республика Удмуртия
• 19 Республика Хакасия
• 20 Республика Чечня
• 21 Республика Чувашия
• 22 Алтайский край
• 23 Краснодарский край
• 24 Красноярский край
• 25 Приморский край
• 26 Ставропольский край
• 27 Хабаровский край
• 28 Амурская обл.
• 29 Архангельская обл.
• 30 Астраханская обл.
• 31 Белгородская обл.
• 32 Брянская обл.
• 33 Владимирская обл.
• 34 Волгоградская обл.
• 35 Вологодская обл.
• 36 Воронежская обл.
• 37 Ивановская обл.
• 38 Иркутская обл.
• 39 Калининградская обл.
• 40 Калужская обл.
• 41 Камчатский край
• 42 Кемеровская обл.
• 43 Кировская обл.
• 44 Костромская обл.
• 45 Курганская обл.
• 46 Курская обл.
• 47 Ленинградская обл.
• 48 Липецкая обл.
• 49 Магаданская обл.
• 50 Московская обл.
• 51 Мурманская обл.
• 52 Нижегородская обл.
• 53 Новгородская обл.
• 54 Новосибирская обл.
• 55 Омская обл.
• 56 Оренбургская обл.
• 57 Орловская обл.
• 58 Пензенская обл.
• 59 Пермский край
• 60 Псковская обл.
• 61 Ростовская обл.
• 62 Рязанская обл.
• 63 Самарская обл.
• 63 Тольятти
• 64 Саратовская обл.
• 65 Сахалинская обл.
• 66 Свердловская обл.
• 67 Смоленская обл.
• 68 Тамбовская обл.
• 69 Тверская обл.
• 70 Томская обл.
• 71 Тульская обл.
• 72 Тюменская обл.
• 73 Ульяновская обл.
• 74 Челябинская обл.
• 75 Забайкальский край
• 76 Ярославская обл.
• 79 Еврейская АО
• 83 Ненецкий АО
• 86 Ханты-Мансийский АО
• 87 Чукотский АО
• 89 Ямало-Ненецкий АО
• 91 Республика Крым
• 92 Севастополь

программ сертификации | OpenText

Страна * — Выберите —AfghanistanAland IslandsAlbaniaAlgeriaAmerican SamoaAndorraAngolaAnguillaAntarcticaAntigua и BarbudaArgentinaArmeniaArubaAscension IslandAustraliaAustriaAzerbaijanBahamasBahrainBangladeshBarbadosBelarusBelgiumBelizeBeninBermudaBhutanBolvia, многонациональное государство ofBonaire, Санкт-Эстатиус и SabaBosnia и HerzegovinaBotswanaBouvet IslandBrazilBritish Индийский океан TerritoryBrunei DarussalamBulgariaBurkina FasoBurundiCambodiaCameroonCanadaCape VerdeCayman IslandsCentral африканских RepublicChadChileChinaChristmas IslandCocos (Килинг) IslandsColombiaComorosCongoCongo, DRCook IslandsCosta RicaCôte d’IvoireCroatiaCuracaoCyprusCzech RepublicDenmarkDjiboutiDominicaDominican RepublicEcuadorEgyptEl СальвадорЭкваториальная ГвинеяЭритреяЭстонияЭфиопияФолклендские (Мальвинские) острова Форое-островаФиджиФинляндияФранцияФранция Остров auGuyanaHaitiHeard и McDonald IslandsHoly Престол (Ватикан) HondurasHong KongHungaryIcelandIndiaIndonesiaIrelandIsle из ManIsraelItalyJamaicaJapanJerseyJordanKazakhstanKenyaKiribatiKorea, Республика ofKuwaitKyrgyzstanLao Народная Демократическая RepublicLatviaLebanonLesothoLiberiaLibyan арабских JamahiriyaLiechtensteinLithuaniaLuxembourgMacaoMacedoniaMadagascarMalawiMalaysiaMaldivesMaliMaltaMarshall IslandsMartiniqueMauritaniaMauritiusMayotteMexicoMicronesia, Федеративные Штаты ofMoldova, Республика ofMonacoMongoliaMontenegroMontserratMoroccoMozambiqueMyanmarNamibiaNauruNepalNetherlandsNetherlands AntillesNew CaledoniaNew ZealandNicaraguaNigerNigeriaNiueNorfolk IslandNorthern Mariana IslandsNorwayOmanPakistanPalauPalestinian край, OccupiedPanamaPapua Новый GuineaParaguayPeruPhilippinesPitcairnPolandPortugalPuerto RicoQatarRéunionRomaniaRussian FederationRwandaSaint BarthélemySaint HelenaSaint Киттс и NevisSaint LuciaSaint Мартин Сен-Пьер и Микелон Сен-Винсент и Гренада inesSamoaSan MarinoSao Том и PrincipeSaudi ArabiaSenegalSerbiaSeychellesSierra LeoneSingaporeSint Маартны (Голландская часть) SlovakiaSloveniaSolomon IslandsSouth AfricaSouth GeorgiaSouth SudanSpainSri LankaSudanSurinameSvalbard и Ян MayenSwazilandSwedenSwitzerlandTaiwan, провинция ChinaTajikistanTanzania, Объединенная Республика ofThailandTimor-LesteTogoTokelauTongaTrinidad и TobagoTunisiaTurkeyTurkmenistanTurks и Кайкос IslandsTuvaluUgandaUkraineUnited арабского EmiratesUnited KingdomUnited StatesUnited Штаты Экваторияльная IslandsUruguayUzbekistanVanuatuVenezuela, Боливарианская Республика ofViet NamVirgin остров , Британские Виргинские острова, U.С.Уоллис и Футуна, Западная Сахара, Йемен, Замбия, Зимбабве,

.

Стандарты компании STO | Центр сертификации Open Cert

Регистрация стандартов компании (или «Стандарты STO»)

Существующая система стандартов состоит из ряда нормативных документов, принятых на национальном и местном уровнях. Однако большинство предприятий, нацеленных на эффективную и плодотворную работу, разрабатывают собственные стандарты, которые становятся обязательными. Стандарты обычно включают перечень требований к рабочему процессу, а также к производимой продукции.

Благодаря стандартам Компании Ваш бизнес получит следующие преимущества:

сокращение расходов на корректировку и пересмотр результатов работы;

оптимизирует потребление ресурсов и, как следствие, снижает расходы

обеспечивает одинаковую рабочую нагрузку всех подразделений;

получите возможность избежать потерь из-за отсутствия четких рабочих инструкций;

имеют меньше шансов на повторение ошибок

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

Кроме того, существует обязательное требование к стандартам компании для продажи определенных типов продуктов, таких как продукты питания или лекарства.

.

Сертификация TOGAF®: как начать работу с индивидуальной сертификацией

Перейти к основному содержанию

• Обновить мой профиль
• Портал сотрудничества
• Войти

Свернуть панель навигации

• Насчет нас
  • Кто мы есть
    • Управляющая компания
    • Правление
    • Избранные представители-члены
    • Руководители форума и рабочих групп
    • Офисы и контакты
    • Набор персонала
  • Что мы делаем
    • Видение и миссия
    • Технологические стандарты
      • Информационная база стандартов
    • Сервисы
      • Разработка программ сертификации
      • Инициативы по новым стандартам для промышленности
      • Наборы тестов
        • Системы UNIX®
        • Системы POSIX®
        • Встроенные системы
        • Другие наборы тестов
      • Службы совместной работы
        • Платон
• Сертификаты
  • Обзор сертификатов
  • Виртуальные учебные ресурсы
  • Открытые значки
  • Профессиональная сертификация — основанная на знаниях
    • Сертификация ArchiMate®
    • Сертификация цифрового практикующего специалиста
    • Сертификация IT4IT ™
    • Открытая сертификация FAIR ™
    • Значки TOGAF® на основе ролей
    • Сертификация TOGAF®
    • Подготовьтесь к сертификации
    • Учебные пособия и практические тесты
    • Сдавать экзамен
    • Экзамены под контролем онлайн
    • Завершите свою сертификацию
  • Сертификационные данные
  • Часто задаваемые вопросы
  • Профессиональные сертификаты — на основе опыта
    • Подготовьтесь к сертификации
    • Сертифицированный архитектор (Open CA)
      • Преимущества
      • Начать
      • Подача заявки на сертификацию Open CA
      • Путь к сертификации Open CA
      • Интерактивная самооценка Open CA
    • Аккредитация программы сертификации
    • Сертифицированный специалист по данным (Open CDS)
    • Сертифицированный технический специалист (Open CTS)
    • Сертифицированный сертифицированный специалист в области технологий (Open CTTP)
  • Продукт | Инструмент | Сертификация процессов
    • Инструменты ArchiMate®
    • POSIX®
    • Инструменты TOGAF®
    • Системы UNIX®
      • Стандарты UNIX®
    • Программа сертификации O-TTPS
  • Реестры сертификации / аккредитации

.

Часто задаваемые вопросы: Сертификаты на основе экзаменов

Перейти к основному содержанию

• Обновить мой профиль
• Портал сотрудничества
• Войти

Свернуть панель навигации

• Насчет нас
  • Кто мы есть
    • Управляющая компания
    • Правление
    • Избранные представители-члены
    • Руководители форума и рабочих групп
    • Офисы и контакты
    • Набор персонала
  • Что мы делаем
    • Видение и миссия
    • Технологические стандарты
      • Информационная база стандартов
    • Сервисы
      • Разработка программ сертификации
      • Инициативы по новым стандартам для промышленности
      • Наборы тестов
        • Системы UNIX®
        • Системы POSIX®
        • Встроенные системы
        • Другие наборы тестов
      • Службы совместной работы
        • Платон
• Сертификаты
  • Обзор сертификатов
  • Виртуальные учебные ресурсы
  • Открытые значки
  • Профессиональная сертификация — основанная на знаниях
    • Сертификация ArchiMate®
    • Сертификация цифрового практикующего специалиста
    • Сертификация IT4IT ™
    • Открытая сертификация FAIR ™
    • Значки TOGAF® на основе ролей
    • Сертификация TOGAF®
    • Подготовьтесь к сертификации
    • Учебные пособия и практические тесты
    • Сдавать экзамен
    • Экзамены под контролем онлайн
    • Завершите свою сертификацию
  • Сертификационные данные
  • Часто задаваемые вопросы
  • Профессиональные сертификаты — на основе опыта
    • Подготовьтесь к сертификации
    • Сертифицированный архитектор (Open CA)
      • Преимущества
      • Начать
      • Подача заявки на сертификацию Open CA
      • Путь к сертификации Open CA
      • Интерактивная самооценка Open CA
    • Аккредитация программы сертификации
    • Сертифицированный специалист по данным (Open CDS)
    • Сертифицированный технический специалист (Open CTS)
    • Сертифицированный сертифицированный специалист в области технологий (Open CTTP)
  • Продукт | Инструмент | Сертификация процессов
    • Инструменты ArchiMate®
    • POSIX®
    • Инструменты TOGAF®
    • Системы UNIX®
      • Стандарты UNIX®
    • Программа сертификации O-TTPS
  • Реестры сертификации / аккредитации

.