Использование Swivel для выполнения требований...

Swivel Secure

Сертификация ФСТЭК

www.swivelsecure.com

Привычные способы аутентификации

•  Высокая стоимость инфраструктуры и управления ей. Необходимость замены/обновления токенов)

•  Неудобны для пользователей (их забывают, теряют и т.п.)

•  Неприменимы для масштабных B2B и B2C приложений

•  Сложные правила провоцируют частое использование одинаковых паролей в разных приложениях

•  Необходимость наличия системы управления изменениями паролей

•  Сложности управления при нерегулярном использовании или использовании третьей стороной

•  Непрактичны для приложений более низкой критичности

Токены

•  Пароли в социальных сетях и корпоративных приложениях часто идентичны

Пароли


Платформа аутентификации Swivel

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

•  Включает в себя более 50 вариантов аутентификации к сотням систем.

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

•  Имеется интеграция для VPN-систем, веб-приложений, облачных решений и рабочих станций.


Сертификация ФСТЭК

•  Имеется положительное решение ФСТЭК на сертификацию продукта

•  Готовятся документы на сертификацию по ТУ и НДВ 4 в системе ФСТЭК

•  Ориентировочная дата получения сертификатов: декабрь 2013


Бестокенная аутентификация. Что дальше?


«Традиционная модель» •  Используется для аутентификации при удаленном доступе

•  Взаимодействие между сервером аутентификации и внутренними ресурсами

•  Все взаимодействие в DMZ

•  Все элементы подконтрольны компании

DMZ Внутренние ресурсы

Интернет


«Федеративная модель» •  Взаимодействие между облачным сервисом и Identity Provider (IdP)

•  Взаимодействие через Интернет

•  Аутентификация на стороне компании, подконтрольна компании, а сервис расположен на стороне облачного провайдера

DMZ

Интернет

ldP


«Гибридная модель» •  Комбинация двух моделей

•  Применяется сегодня

•  Та самая «Единственная платформа аутентификации, которая нужна»

•  Схема сегодня устраивает почти всех. Что дальше?


Интернет

ldP


Интерфейс общения с пользователем •  У предприятий самые разные требования к этому элементу

•  Главное требования – высокая гибкость настройки для администратора и пользователя

•  Та самая «Единственная страница аутентификации, которая нужна»


Интернет

ldP

Портал аутентификации


Строится по «федеративной модели» •  Решения SAML, ADFS, OpenID, Open Auth собираются в единый модуль (Портал

аутентификации)

•  Все запросы на доступ проходят через Портал аутентификации

SAML ldP

ADFS STS

Open Auth

Интернет

Портал аутентификации пользователя


«Будущая» схема бестокенной аутентификации

DMZ

Интернет

Портал аутентификации


Основные требования к сертификации

•  Клиент-серверная архитектура

•  Проверка на НДВ

•  Проверка в рамках ТУ требований по доступу и аутентификации:

•  152-ФЗ,

•  Профиль защиты средства двухфакторной аутентификации,

•  НПС,

•  СТО БР ИББС,

•  27001,

•  PCI DSS,

и др.


21 приказ ФСТЭК по ПДн. Требования по аутентификации «+»

+ другие требования


Профиль защиты средства двухфакторной аутентификации


НПС (382-П)


СТО БР ИББС

•  7.4.3. В организации БС РФ должны быть документально определены и утверждены руководством, выполняться и контролироваться процедуры идентификации, аутентификации, авторизации; управления доступом; контроля целостности; регистрации событий и действий.

•  Процедуры управления доступом должны исключать возможность “самосанкционирования”.

…

•  7.4.11. В организации БС РФ должны применяться защитные меры, направленные на обеспечение защиты от НСД и НРД, повреждения или нарушения целостности информации, необходимой для регистрации, идентификации, аутентификации и (или) авторизации клиентов и работников организации БС РФ. Все попытки НСД и НРД к такой информации должны регистрироваться. При увольнении или изменении должностных обязанностей работников организации БС РФ, имевших доступ к указанной информации, необходимо выполнить документированные процедуры соответствующего пересмотра прав доступа.

…


PCI DSS (Назначить уникальный идентификатор каждому лицу, имеющему доступ к информационной инфраструктуре)

8.1 Назначение пользователям уникальных идентификаторов

8.2 Механизмы аутентификации пользователей

8.3 Механизм двухфакторной аутентификации

8.4 Передача и хранение паролей в зашифрованном виде

8.5 Процедуры аутентификации пользователей и управления паролями учетных записей

8.5.1 Контроль над добавлением, удалением и изменением объектов идентификации

8.5.2 Проверка подлинности пользователя перед сменой пароля

8.5.3 Установка уникального первоначальный пароль и его смена при первом входе в систему

8.5.4 Отзыв доступа при увольнении пользователя

8.5.5 Удаление/блокировка неактивных учетных записей

8.5.6 Контроль над учетными записями поставщиков

8.5.7 Информирование пользователей о положениях парольных политик и процедур

8.5.8 Запрет использования групповых, разделяемых и стандартных учетных записей и паролей

8.5.9 Периодичность изменения пароля пользователя

8.5.10 Длина пароля

8.5.11 Использование в пароле цифровых и буквенных символов

8.5.12 Запрет выбора использованного ранее пароля

8.5.13 Блокировка учетной записи после неудачных попыток ввода пароля

8.5.14 Период блокировки учетной записи

8.5.15 Блокировка рабочей сессии

8.5.16 Аутентификация доступа к базе данных, содержащей данные о держателях карт

Спасибо за внимание!

Использование Swivel для выполнения требований...

Documents

Transcript of Использование Swivel для выполнения требований...