ARinteg.ru

  • Москва
  • Ростов-на-Дону
  • Кемерово
  • Новосибирск

  • +7 (495) 221 21 41
  • +7 (863) 320 09 60
  • +7 (384) 221 56 41
  • +7 (495) 221 21 41
ARinteg Вконтакте Дзен ARinteg Arinteg Telegram home print mail site-map               

Дискуссионный клуб темы номера "ИКС" №9'2012 "Дорожная карта облачной безопасности". Он-лайн версия. Часть 2.

Сентябрь 2012, №9 / Журнал "ИКС"

"ИКС": Какова специфика инфобезопасности для каждой из трех моделей облачных услуг,  какая из них отличается наиболее высоким уровнем безопасности, какая – наименьшей степенью? Чем это объясняется?

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

Валерий Андреев, заместитель директора по науке и развитию, ЗАО ИВК: Начать следует, разумеется, с общего. Одним из наиболее специфических облачных свойств является виртуализация (по крайней мере, для облаков, использующих в составе решения и продукты компании VMware). Наличие уже одного этого свойства облака подводит рынок к решению ключевой проблемы - защиты виртуальной среды, исполненной на уровне гипервизора. Не так много ИБ-решений, работающих таким образом, и уж вовсе их практически полное отсутствие, имеющих легитимность на российском рынке ИБ. Дальнейший процесс оркестровки ресурсов в облаке для реализации конкретного вычислительного процесса (приложения) вовсе никак не легитимен, по причине отсутствия необходимой нормативно-правовой базы и полной растерянности регулятора.

Но и специфика, безусловно, имеется. Она связана с самой сутью каждой из моделей. Модель SaaS предусматривает предоставление пользователю необходимого набора приложений облака, так что в облаке пользователь хранит только данные. Все вопросы, связанные с обеспечением ИБ в отношении приложений, провайдер берет на себя. А вот данные пользователя он обязан защитить надлежащим образом, что он и гарантирует пользователю (и о чем доказывает регулятору). Здесь провайдеру необходимо представить средства контроля доступа к этим данным, средства сигнализации (при НСД к этим данным), средства, обеспечивающие конфиденциальность и целостность данных пользователя и пр.

Модель PaaS является основой для миграции в облака не данных, но приложений. К примеру, такой платформой может быть Microsoft.NET. Тогда провайдер, в первую очередь, обеспечивает доступ не к данным, а к сервисам единого вычислительного процесса, например, сервису хранения (SQL или иное). Здесь ключевым моментом являются возможности сервера приложений этой платформы, они различаются, и поэтому на сегодняшний день нет единого подхода к SLA в облаке. В части ИБ такая модель должна обеспечивать дополнительно к SaaS контроль доступа к этому самому серверу приложений со стороны процесса (приложения) пользователя, что напрямую упирается в особенности функционирования виртуальной среды. Таким образом, возникает два типа контроля доступа: пользователь-приложение (обеспечивается пользователем); приложение-сервер приложений (обеспечивается провайдером).

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

Александр Санин, коммерческий директор компании Avanpost: Модель SaaS отличается бОльшим уровнем безопасности, нежели PaaS и IaaS, связано это с несколькими факторами. Если говорить кратко, то для начала нужно отметить, что очень большой «проблемой» в безопасности являются сами пользователи. Т.е. если у пользователя на его устройстве, с которого он получает доступ в облако, нет никаких защитных механизмов гигиенического характера (антивирус, файервол, не стоят обновления системного ПО), то автоматически такой пользователь становится огромной угрозой. Теперь если говорить о моделях предоставления услуг в облачных сервисах, то как раз в модели SaaS такой пользователь является не такой уж страшной угрозой. Ведь SaaS сервис сильно ограничивает пользователя, и фактически оперирует только теми данными, которые пользователь сам же туда внес, не давая ему никакой возможности привнести в «облако» какой-то зловредный код. В моделях же PaaS или IaaS такой пользователь, чисто теоретически, может доставить куда больше проблем – ведь ограничений на то, что пользователь туда принесет, нет.

Артем Гарусев, исполнительный директор компании CDNvideo: Невозможно ответить на этот вопрос, т.к. не определены точно угрозы, о которых идет речь. Разница между SaaS, PaaS и IaaS в том, какая часть инфраструктуры и бизнеса аутсорсится, а какая остается в зоне клиента. Соответственно, угрозы и методы борьбы различны, сравнить просто по критерию лучше-хуже невозможно.

Александр Колыбельников, эксперт по информационной безопасности «Микротест»:  Есть три модели: инфраструктура как сервис (IaaS), илатформа как сервис (PaaS) и программное обеспечение как сервис (SaaS). Иерархия этих услуг ровно такая, как я назвал: сначала инфраструктура, потом платформа, затем софт. Соответственно, чем ниже уровень, тем безопаснее данная услуга. Это связано с тем, что если, допустим, мы используем ПО как сервис, это означает, что вопросы безопасности платформы и инфраструктуры никуда не ушли, просто эти вопросы перекладываются на сервис-провайдера, а степень их готовности, степень их решения зависит также от провайдера. Получается,  что мы доверяемся провайдеру и все зависит только от него.

Денис Безкоровайный, технический консультант Trend Micro в России и СНГ: Чем выше степень контроля за облачным сервисом у клиента (потребителя облачных сервисов), тем большую ответственность он несет и за обеспечение информационной безопасности этого сервиса. Так, в случае IaaS модели провайдер услуги контролирует физическую серверную и сетевую инфраструктуру, систему хранения данных, систему управления виртульными машинами и должен защищать эти компоненты. Вся остальная безопасность на уровне ОС и приложений, например, установка патчей безопасности, антивирусная защита, управление доступом к ОС и приложениям, обнаружение вторжений, контроль действий администраторов – задача клиента IaaS сервиса. В SaaS наоборот, клиенту достается меньше всего забот по ИБ, так как практически все контролируется провайдером – клиент лишь управляет разграничением доступа к данным приложения, настраивает систему аутентификации, иногда может использовать системы шифрования данных.

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

Владимир Удалов, руководитель направления корпоративных продуктов в странах развивающихся рынков «Лаборатории Касперского»: Модель IaaS дает клиенту наибольшую свободу: компания может сама выбирать и контролировать сервера, сетевое оборудование, операционные системы, средства виртуализации, и, разумеется, используемое программное обеспечение. Обеспечение безопасности в этом случае также ложится на плечи компании-клиента, а точнее на ее IT-службу, от профессионализма и грамотности которой и будет зависеть уровень защиты. Преимуществом здесь является тот факт, что компания имеет возможность самостоятельно определять перечень мер по защите информации, проводить аудит информационной безопасности. Однако если у компании-клиента не окажется квалифицированных специалистов по информационной безопасности, вся эта инфраструктура может оказаться под угрозой из-за недостаточного уровня обеспечения безопасности.

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

Федор Гриценко, директор управления аутсорсинга ФК СЦ компании "Ай-Теко":  Один из критичных аспектов развития гибридных и публичных облаков – технологическое обеспечение безопасности данных, которые в них хранятся. Эта задача находится в фокусе внимания всех крупнейших вендоров облачных сервисов, так как ее решение дает огромное конкурентное преимущество – доверие пользователей.  Однако есть определенные различия к требованиям для SaaS, IaaS и PaaS решений с точки зрения безопасности. Это обусловлено тем, что сегодня решения SaaS больше востребованы частными пользователями, а IaaS и PaaS – корпоративным сегментом.

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

Юрий Сергеев, системный архитектор Центра информационной безопасности компании «Инфосистемы Джет» : Говоря о специфике обеспечения информационной безопасности для каждой из моделей публичных облачных услуг, следует помнить, что ключевой вопрос, на который следует ответить, обеспечивая безопасность облака, – "Кем и в каком объеме контролируются его ресурсы?". Безопасность  облачных сервисов не является абсолютной прерогативой оператора – частично за неё несет ответственность и подписчик сервиса. К примеру, оператор, обеспечивший IaaS-услугу, обычно не имеет возможности контролировать дальнейшие действия подписчика, который устанавливает или настраивает дополнительные программные компоненты. В случае оказания PaaS-услуг, провайдер не может дать 100%-ных гарантий, что подписчики правильным образом разработают свою программу на предоставляемой платформе. Оператор SaaS-услуги, в свою очередь, не  обещает, что сотрудники будут обеспечены правами доступа в рамках своих ограниченных административных прав на уровне приложения подписчиком и что последний должным образом отследит базовые правила использования идентификационных данных. При этом задача оператора, с точки зрения информационной безопасности, – создать базовую защищенную среду, в которой данные разных подписчиков услуг будут изолированы друг от друга, а также – обеспечить контроль действий администраторов. Облачные провайдеры априори должны обеспечивать достаточный уровень защиты, чтобы клиент их не побоялся выбрать, поэтому их нацеленность на результат позволяет им защищать облако более эффективно, чем это может делать каждый отдельный пользователь услуги. Поэтому та модель, в которой у провайдера больше зона технической ответственности (SaaS), может отличаться наиболее высоким уровнем безопасности. Но дьявол в деталях, и, в конечном счете, все сильно зависит от реализации.

Антон Разумов, Руководитель группы консультантов по безопасности Check Point Software Technologies Ltd: Разумеется, подходы к обеспечению безопасности разных сервисных моделей весьма различны. IaaS: арендуется инфраструктура. При этом заказчик самостоятельно устанавливает и администрирует операционные системы, приложения… И обеспечить своими силами безопасность серверов, расположенных «где-то» весьма не просто. PaaS: арендуется платформа, например, Google AppEngine или Windows Azure. В этом случае следует заботиться только о безопасности своих приложений. Это несколько проще, чем в предыдущем случае. SaaS: в данном случае практически все заботы о безопасности берет на себя провайдер. Можно исходить из предположения, что у крупного поставщика услуг штат разработчиков, специалистов по безопасности, значительно больше и качественнее, чем у конечного заказчика, разрабатывающего собственное приложение. Как показывают недавние исследования, в самописном ПО действительно имеется значительное количество ошибок. К сожалению, в силу единичных копий, о них мало известно широкой общественности, поэтому обнаруживший уязвимость может спокойно эксплуатировать ее длительное время.

Вячеслав Медведев, аналитик компании "Доктор Веб": Во всех трех случаях требования по безопасности не должны отличаться. Дело в том, что по сути все три термина описывают лишь разный уровень доступа администраторов клиентов к предоставляемым ресурсам. В случае IaaS (Infrastructure as a Service) администраторы получают под свой контроль виртуальные системы и делают на них что угодно, не имея доступа лишь на уровень гипервизора и системы резервного копирования виртуальных машин. В случае PaaS за безопасность на уровне виртуальной машины отвечает уже провайдер услуги. На уровне SaaS провайдер услуги отвечает уже практически за все аспекты безопасности предоставляемой услуги. Но кто бы ни отвечал за те или иные части услуги (виртуальную машину, операционную систему, на ней установленную, сервис, действующий на базе операционной системы, и многое другое) — требования, предъявляемые к безопасности, в общем не различаются. Таким образом, какую бы модель клиент ни выбрал, и какую бы модель провайдер ни предоставлял — требования должны быть едиными. Разница состоит лишь в том, кто должен реализовывать те или иные меры безопасности. Тем самым мы снова возвращаемся вопросу зрелости рынка безопасности. Ситуация на данный день такова, что клиенты не представляют реального уровня рисков, которым подвергаются их ИТ-системы, где бы они ни находились — в облаке или локально. В этих условиях провайдерам нет смысла переламывать рынок и заставлять клиентов использовать необходимые средства безопасности. Тем более что под средствами безопасности специалисты в области ИБ и большинство клиентов понимают совершенно разное. Клиенты считают, что работа по обеспечению безопасности начинается и заканчивается установкой программного и аппаратного оборудования. Специалисты же по ИБ говорят, что основная угроза — это пользователи, и для надежной защиты мало поставить ПО, нужно обучать пользователей безопасной работе, доводить до них сведения о последствиях тех или иных действий, контролировать состояние системы безопасности и постоянно ее совершенствовать.

Дмитрий Слободенюк, директор компании ARinteg: В разных типах облаков существуют разные группы рисков в зависимости от специфики работы и локализации приложений. Например, в модели SaaS приложения локализованы в «облаке», поэтому риск представляет использование нескольких учетных записей для доступа к приложениям. Проблема решаема унификацией учетных записей для облачных и локальных систем путем создания, например, «единого входа» для каждого пользователя – при этом доступ к сервисам они получают при помощи всего одной учетной записи, что значительно упрощает контроль.

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

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

Джабраил Матиев, руководитель группы информационной безопасности IBS Platformix: Я бы поставил вопрос по-другому: как разделяются зоны ответственности при обеспечении информационной безопасности между пользователем и провайдером облачной среды в разных моделях.

Если попробовать выразить ответственность в процентном соотношении, то ориентировочное распределение будет выглядеть следующим образом:

SaaS: пользователь – 1% (конфиденциальность аутентификационных данных), провайдер – 99% (обеспечение всех уровней защиты)

PaaS: пользователь 20% (защита приложения), провайдер – 80% (защита инфраструктуры и платформ)

IaaS: пользователь 80% (защита приложений и платформ), провайдер – 20% (защита инфраструктуры).

С точки зрения потребителя вариант SaaS будет более безопасным (при условии, что провайдер обеспечил должный уровень защиты). В случае IaaS потребитель сам должен обеспечить большую часть механизмов защиты, в этом случае велик риск, что система не будет отвечать требованиям безопасности.

Владимир Алеев, главный архитектор бизнес-решений: центры обработки данных, ОАО «СИТРОНИКС»: Уровень информационной безопасности определяется не только и не столько моделью публичных облачных услуг, сколько характером данных, которые при этом обрабатываются, и ИТ-сервисами, которые компании выносят в публичные «облака». На сегодня ни одна из указанных моделей не отвечает в полной мере требованиям по защите данных высоких категорий (выше 1Г). Коммерческие компании, планирующие перенос некоторых своих приложений и ИТ-сервисов в публичные «облака», обычно сохраняют чувствительные данные в собственных ЦОДах. Это относится как к российским, так и к зарубежным компаниям, даже при том, что юридическая основа «облачных» ИТ-услуг в их странах может быть более надежной, чем в нашей.

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

Модель PaaS используется преимущественно для разработки  и тестирования ПО. В этих случаях требования по защите обрабатываемых данных, как правило, невысоки, но оказываются уязвимыми программные коды, которые могут представлять интеллектуальную собственность компании-клиента PaaS.

В модели SaaS обеспечить надежную и гарантированную защиту информации  при использовании публичных облачных услуг может сильная посредническая организация, которая берет на себя функции регулятора в отношениях поставщиков и получателей облачных услуг и обеспечивает безопасный информационный обмен. Например, в США такой организацией является Global Service Administration. В России "Ростелеком", будучи оператором электронного правительства, взял на себя аналогичные функции.

Михаил Башлыков, руководитель направления информационной безопасности компании КРОК: Специфика обеспечения инфобезопасности зависит от того, насколько настраиваемой является услуга с точки зрения конечного пользователя. Например, для услуг IaaS и PaaS характерно, что пользователь способен самостоятельно выполнять настройку облачного сервиса, а это влечет за собой определенные угрозы для ИТ-инфраструктуры. В данном случае облачному провайдеру необходимо предусмотреть дополнительные механизмы защиты, которые  могут предоставляться опционально.

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

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

Неманья Никитович, управляющий директор OptimaInfosecurity (Группа Optima): Говоря о каждой из моделей, не стоит забывать, что прежде всего речь идет о бизнес-моделях, то есть о моделях предложения сервиса. Уровень безопасности диктует не модель облачных сервисов, а требования бизнеса (заказчика) к критичности тех или иных бизнес-приложений или информационных систем, такие как требования к непрерывности их функционирования, целостности и защищенности от утечек информации, потери данных и других уязвимостей.

Владимир Ткачев, технический директор VMware, Россия и СНГ: Сравнивать модели предоставления услуг по степени безопасности не совсем корректно. Можно говорить о том, что IaaS наиболее похожа на "традиционную" модель ЦОДа, поэтому и точки уязвимостей и способы защиты более привычны специалистам по ИБ. Косвенно это может повлиять на качество организационно-технических мер, называемых общим словом "безопасность". PaaS, как и Saas, уже провоцируют к разговору в совершенно новой сфере задач, таких как безопасность при разработке ПО, независимость от поставщика услуг и от вендора подлежащего ПО. Возможно, не все специалисты по ИБ знакомы с этими рисками и могут их взвешенно учитывать, но ситуация быстро меняется.

Алексей Лукацкий, бизнес-консультант по безопасности Cisco Systems: Специфика обусловлена уровнем контроля над элементами облачной инфраструктуры. В SaaS он минимален – я, как пользователь, отвечаю только за данные, загружаемые в облако. В PaaS я отвечаю за чуть большее число элементов. В IaaS их еще больше. Но все зависит не столько от уровня безопасности, сколько от уровня контроля над тем, что делается у облачного провайдера. Если контроля нет, то об уровне безопасности говорить вообще нельзя. Как можно оценивать уровень того, что не контролируешь.

Илья Трифаленков, начальник отдела информационной безопасности ОАО «Ростелеком»: Наиболее высокий уровень безопасности – SaaS, поскольку именно в этой модели преимущества облаков, такие как разделение администрирования на прикладном и инфраструктурном уровне, возможность предоставления услуги заданного SLA, разделение зон ответственности оператора и пользователя.

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

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

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

Александр Трошин, технический директор «Манго Телеком»: На мой взгляд, уже в самом этом вопросе есть ментальная ловушка, в которую попадает большинство предприятий. С точки зрения ИБ, эти три модели отличаются, прежде всего, тем, где походит граница между зонами ответственности провайдера и пользователя. При этом даже в SaaS, где максимум ответственности лежит на провайдере, остается очень значительная зона, за которую отвечает пользователь. А злоумышленники, как известно, штурмуют не самый защищенный бастион, а находят самое слабое звено в системе защиты. Именно оно и определяет уровень защищенности всей системы. В зависимости от соотношения квалификации поставщика и провайдера в плане ИБ, получается совершенно разное распределение общей защищенности.

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

Если же в плане ИБ сильнее провайдер, то распределение будет противоположным. Конечно, это упрощенная схема, только иллюстрирующая общую идею. ИБ – это сложнейший комплекс вопросов, где высокая квалификация в одних вопросах вполне может уживаться с крайне низкой в других. Разумеется, кроме квалификации надо учитывать и возможности, ведь защищает не правильная схема, а работающая организационно-техническая система. На практике термин «квалификация в ИБ» чем то напоминает среднюю температура по больнице. Тем не менее, схема рассуждений работает – несмотря на сложности объективного сравнения квалификации сторон (и возможностей) в конкретных случаях.

Если все же говорить об общих закономерностях, то в SMB уровень ИБ ниже, чем у повайдера, причем этот разрыв, пожалуй, только увеличивается во времени.  В любом случае, конкретному заказчику, формирующему собственную стратегию, нужно постараться непредвзято посмотреть на собственный отдел ИБ, а потом – смотреть на фактические свойства решений SaaS, PaaS и IaaS. В рамках каждой модели обычно прописывается весь возможный функционал и, конечно, все возможные обязательства провайдера. Поэтому я не скажу, что для какой то модели уровень ИБ более высок, а для какой то – низок. Есть уровни, приемлемые для заказчика, а есть неприемлемые.

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

Далее идет SaaS. SaaS – это решение комплексное. И здесь все описывается свойствами software, которые клиент берет как сервис у поставщика услуг. При этом он, естественно, может видеть риски. Если какие то риски не заложены, скорее всего, они — на стороне провайдера, а не на стороне заказчика. И уже провайдер обязан за них отвечать.

В случае же с PaaS, пожалуй, невозможно сказать, чьи конкретно там риски. И вообще, разграничить внутри этой модели риски по ИБ, пожалуй, наиболее сложно. Так как непонятно (и непредсказуемо), где именно может возникнуть «дырка» — на уровне аппаратного или программного комплекса самого заказчика и как эти риски расписать.

Теги:

Перейти к списку статей
qrcode
ARinteg Вконтакте   Дзен ARinteg   Arinteg Telegram