В «облака» издалека

15 сентября 2013

Автор: Константин Закатов, специалист отдела специальных проектов и технической защиты информации Центра Разработок производственной компании «Аквариус».

Спецприложение «Бизнес & информационные технологии» к журналу «Системный администратор» №7, Сентябрь 2013.

Если обобщить некоторые материальные ценности, которые можно внести в депозитарную ячейку банка, в чем-то похожие на информацию ограниченного доступа, назвав их общим словом «объект», то эти вопросы можно сформировать следующим образом:

· Как будет обеспечена безопасность объекта, физически расположенного стационарно, его доступность и целостность?

· Как будет организован безопасный и персонализированный доступ к объекту лицом, имеющим на это право?

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

Второй же вопрос зачастую пользователь должен решать самостоятельно, разбивая его на множество более мелких:

· как добраться до банка, имея при себе ценности;

· как в любой момент времени убедиться, что с хранимым все в порядке;

· как своевременно получить необходимую информацию, расположенную в хранилище, и т.д.

Организация защищенного доступа к облачным хранилищам по многим параметрам более трудоемка и требует комплексного подхода.

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

Для установления защищенного соединения между клиентом и сервером применяются технологии, основанные на шифровании трафика различными способами – начиная от транспортных механизмов SSL и TLS и заканчивая полноценными, часто аппаратными VPN.

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

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

Ключевые особенности решений:

· Возможность функционирования рабочих станций в системе электронного документооборота с применением средств электронной подписи.

· Использование в качестве идентификаторов USB-токенов и смарт-карт различных производителей;

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

Более подробно описания решений приведены ниже.

Описание: Рисунок 1. Тонкий клиент Aquarius CMP TCC U30 S20

Рисунок 1. Тонкий клиент Aquarius CMP TCC U30 S20

Вариант 1 (архитектура x86)

Аппаратная платформа тонкого клиента Aquarius CMP TCC U30 S20 (архитектура x86) предполагает два варианта исполнения:

· Win-ТК, обеспечивает базовый уровень защиты посредством шифрования только HTTP-трафика;

· Lin-ТК, обеспечивает расширенный уровень защиты с шифрованием всего трафика, курсирующего между клиентом и сервером.

Состав и различие исполнений указано в таблице 1.

Таблица 1. Состав и различие исполнений тонких клиентов Aquarius CMP TCC U30 S20

Win-TK

Lin-TK

Операционная система

ОС Microsoft Windows Embedded

Альтлинукс СПТ 6.0 32-bit

Специальное ПО

Крипто ПРО 3.6 R2

ViPNet Client 3.2

Антивирус

Dr.Web Desktop Security Suite

Особенности Win-ТК:

· Шифруется только трафик, передаваемый по протоколу HTTP.

· Интерфейс операционной системы практически идентичен привычным интерфейсам операционных систем Windows XP и Windows 7 (в зависимости от версии), что обеспечивает удобство работы пользователей.

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

В данном варианте защищенное HTTPS-соединение между тонким клиентом и веб-сервером организуется c использованием протокола TLS 1.0 на продуктах компании «Крипто Про». При этом возможны два варианта аутентификации – аутентификация по сертификатам только на стороне сервера и обоюдная аутентификация при доступе к веб-серверу.

Во всех вариантах передаваемый по протоколу HTTP трафик шифруется с использованием российского криптографического алгоритма ГОСТ 28147-89.

Для разграничения доступа c тонких клиентов к ресурсам внешней сети в учреждении в качестве шлюза должен использоваться сертифицированный МСЭ, например, ПАК aQuaUserGate или ПАК aQuaInspector.

Описание: Рисунок 2. Схема функционирования Win-TK

Рисунок 2. Схема функционирования Win-TK

Особенности Lin-ТК:

  • Шифруется весь трафик, передаваемый от тонкого клиента до сервера вне зависимости от клиентского программного обеспечения.
  • Возможность использования для защиты соединения по протоколам ICA, RDP и другим протоколам клиент-серверных приложений.
  • Возможность использования функций электронной подписи (при условии поддержки данной функции прикладным прог-раммным обеспечением).
  • Отсутствие необходимости применять сертифицированные МСЭ экраны на границе ЛВС (сертифицированный МСЭ реализован в специальном программном обеспечении).

В данном варианте c клиентского рабочего места до границы ЛВС ЦОД организуется защищенный VPN-туннель, при этом весь передаваемый трафик шифруется с использованием российского криптографического алгоритма ГОСТ 28147-89.

Функционирование защищенного тонкого клиента осуществляется в составе развернутой защищенной сети ViPNet:

  • на границах ЦОД установлены криптомаршрутизаторы, например, ПАК ViPNet Coordinator HW‑1000 или HW-2000 (в зависимости от требуемой производительности шифрования трафика);
  • в ЦОД расположен АРМ Администратора сети ViPNet Custom (Удостоверяющий ключевой центр и Центр управления сетью), с помощью которого осуществляется конфигурирование защищаемой сети ViPNet и определяются связи между клиентами защищаемой сети.

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

Помимо организации защищенного канала, ViPNet Client также имеет в своем составе сертифицированный ФСТЭК межсетевой экран по классу 4 (МСЭ).

Описание: Рисунок 3. Схема функционирования Lin-TK

Рисунок 3. Схема функционирования Lin-TK

Вариант 2 (архитектура ARM)

Тонкий клиент Aquarius CMP M10 S12 на платформе ARM v5, функционирующий под управлением операционной системы AquaNixStd и со встроенным VPN-клиентом ViPNet Client (сертификат ФСБ и ФСТЭК).

Описание: Рисунок 4. Тонкий клиент Aquarius CMP M10 S12

Рисунок 4. Тонкий клиент Aquarius CMP M10 S12

В состав решения входят:

  • ОС AquaNixStd;
  • ViPNet Client 3.2.

· Преимущества:

  • Шифруется весь трафик, передаваемый от тонкого клиента до сервера вне зависимости от клиентского ПО.
  • Возможность использования для защиты соединения по протоколам ICA, RDP и другим протоколам клиент-серверных приложений.
  • Отсутствие необходимости применять сертифицированные МСЭ экраны на границе ЛВС (сертифицированный МСЭ реализован в специальном программном обеспечении).
  • Схема функционирования приведена на рис. 5 и функционально идентична схеме, предложенной для Lin-TK.

Описание: Рисунок 5. Схема функционирования ARM-TK

Рисунок 5. Схема функционирования ARM-TK

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

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

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

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

Источник: http://bit.samag.ru/archive/article/1300

Еще новости по тегам:
Еще новости по тегам:
Предыдущая новость
Следующая новость
07 сентября 2013