Что нового?

Дата вебинара: 13 марта 2013 года
Стенограмму подготовил Сергей Проуторов

Отчет о вебинаре доступен здесь.

Здравствуйте, меня зовут Владимир Мельник и сегодня мы начинаем очередной, четвертый по счету вебинар, тема которого – «Безопасность в облаке». О безопасности в облаке мы будем говорить не только как о безопасности собственно в облаке, но и вне его, поскольку информационная безопасность – понятие сложное и многокомпонентное. И ее нельзя рассматривать, как безопасность только в облаке или вне его. Использование облачных вычислений подразумевает определенные дополнения ко всему тому, что мы уже знаем о безопасности. Потому что классическая инфраструктура – то, к чему многие уже привыкли. Многие уже имеют огромный опыт обеспечения информационной безопасности в классической инфраструктуре. А инфраструктура облачная или гибридная – для многих тема достаточно новая. И, конечно же, мы будем рады поделиться накопленным опытом по обеспечению безопасности в таких системах, которые либо полностью вынесены в облако, либо являются гибридными.

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

Или, например, веб-сервер позволяет заливать на него обычным пользователям из Интернета любые файлы из-за какой-то «дырки» в скриптах и потом эти файлы позволяет запускать. Злоумышленник через какую-нибудь форму, относительно которой разработчик не предусмотрел, что она будет себя так вести, «заливает» кажущийся безобидным файл, затем делает так, чтобы этот файл исполнялся, он исполняется уже от самого веб-сервера и это приводит к тому, что злоумышленник получает права на запись или чтение какой-либо информации, которая к нему попасть не должна была. Это, пожалуй, самый сложный для диагностики и мониторинга способ, который вообще только есть – «дыра» в безопасности. Это недостаточная программная защита. Диагностировать ее очень сложно. Для анализа даже очень простой системы, чтобы понять, насколько она действительно защищена, требуется очень много времени и человеческих ресурсов. Почему? Потому что для того, чтобы продиагностировать, насколько ПО в той или иной системе настроено корректно, насколько правильно оно написано – на это действительно требуется время, потому что компания, проводящая аудит, как правило, должна не только осмотреть саму систему, но и протестировать ее всеми возможными методами. То есть, она должна попытаться эту систему взломать всеми способами, которые есть в их опыте. Поэтому анализ ПО может затянуться очень и очень надолго. И он является очень часто используемым фактором при взломе каких-либо систем – будь то облачных или построенных на классической инфраструктуре.

Подытоживая, скажу, что всегда есть какое-то ПО, которое «смотрит» и в Интернет, и в локальную сеть, и куда угодно, и через это ПО очень часто систему могут взломать и при этом, к сожалению, системный администратор об этом до поры до времени даже не подозревает. Очень часто бывает, что система вроде бы хорошо работает, все прекрасно, несколько лет она проработала, и на пятый год ее взломали и украли какие-то данные или нагадили на главной странице веб-сайта. Почему это произошло? Потому что не устанавливались критические обновления, злоумышленники узнали о том, что используется устаревшая версия, например, FTP-сервера, воспользовавшись ошибкой в FTP-сервере, они получили над ним контроль и изменили какие-то файлы. То есть, недостаточная программная защита.

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

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

Если же мы говорим об облачной инфраструктуре, то, говоря по правде, переход в облако вовсе не является гарантией того, что человеческий фактор перестанет представлять собой угрозу. Но он облегчает работу специалистов по информационной безопасности в плане контроля пользовательских компьютеров. Что я имею в виду? Во-первых, пользователю уже несколько труднее перегнать свои данные на флешку. Да, конечно, RDP-протокол позволяет подключиться по RDP к серверу терминального рабочего стола и позволяет получить доступ к своему флеш-устройству, которое пользователь воткнул в тонкий клиент. Но, как правило, в облаке системные администраторы запрещают эту функцию намертво. Потому что в том случае, если пользователю действительно необходимо перегнать какие-то данные с флешки или на флешку, то он приносит свою флешку в службу технической поддержки и заполняет заявку о том, что ему необходимо передать какие-то данные. И IT-администраторы предприятия выполняют это самостоятельно. Это позволяет обеспечить определенного рода гарантию того, что с флешки в систему не проникнет какой-нибудь зловредный код, или на эту флешку не попадут из облака данные, которые туда попасть не должны. Поэтому в облаке этот момент гораздо проще контролировать. Более того, как вы знаете, существует достаточно много программного обеспечения, которое позволяет организовать действительно настоящий контроль над действиями пользователя. И речь даже не только о протоколировании того, куда этот пользователь ходил и какие программы открывал. Существует ПО (которое прекрасно работает, кстати, и в TUCHA, некоторые наши заказчики им пользуются, насколько я знаю) которое позволяет не только собирать статистику по тому, как именно пользователь расходовал свое рабочее время, но и позволяет вести запись клавиатурных нажатий, позволяет делать с определенной частотой, задаваемой администратором, снимки экрана и т.п.

Когда пользователи предприятия уведомлены о том, что такая система внедрена и работает, это радикально увеличивает производительность труда, как показывает практика, и уменьшает риск того, что какой-то из пользователей захочет передать какой-нибудь экселевский файл себе на джимейловский ящик. Просто потому, что он знает, что все, что он делает, может быть проанализировано, что оно записывается и при каких-то разборках может всплыть. Следовательно, когда пользователь знает о том, что его действия мониторятся, то угроза от него как от «человеческого фактора», который умышленно желает нанести вред предприятию, сильно снижается. Что же касается неумышленных ситуаций, когда, например, какие-то данные были случайно отправлены на флешку, то защита от копирования данных и от работы с флеш-накопителями в этом плане очень выручает. В связи с этим риск того, что человеческий фактор может привести к каким-то серьезным проблемам, действительно несколько снижается. Если говорить о недостаточной аппаратной защите, которая тоже бывает неприятным и скользким моментом, то мы можем вспомнить (если сегодня кто-то с утра заходил в Интернет и просматривал новости) сегодня в очередной раз менты напали на компанию Global Logic в Харькове. Там в начале года, насколько я помню, уже что-то было, приходили в офис, чего-то хотели, парализовали работу на 1-2 дня, а сегодня – такая новость: пришли и начали все изымать из офиса в Харькове.

Тут уже говорить о действиях разного рода так называемых правоохранительных органов приходится слишком часто, поэтому если абстрагироваться от такого фактора, то возьмем, к примеру, простейшую вещь: есть офис, данные хранятся в офисе, случился пожар и всё, «мы приехали». Да, хорошо когда есть бэкапы, которые сбрасывались куда-то, а кстати, куда сбрасываются бэкапы? А бэкапы сбрасываются в какую-то изолированную среду, например, в то же облако. Можно сбрасывать бэкапы в облако и хранить данные у себя в офисе, а можно «жить» в облаке и сбрасывать бэкапы себе в офис. Так или иначе, в том случае если речь идет об аппаратной защите и хранении каких-то данных в офисе, то это всегда фактор риска. Почему?

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

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

Они говорят: «Хорошо, предположим, мы доверим вам нашу информацию. Прекрасно. Но получается, что мы будем иметь доступ к своей информации через Интернет». Да, совершенно верно, пользователь будет иметь доступ к своей информации через Интернет. И очень часто потенциальный клиент задает такой вопрос: «Получается, что кто-то будет иметь доступ к моей информации через Интернет? Это очень опасно». Это действительно очень опасно. Мы не рекомендуем оставлять доступ к сервисам, развертываемым в нашем облаке, через Интернет. Объясню, почему.

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

Для этого есть замечательная штука – VPN. Что это такое, наверняка знают все, кто присутствуют. На всякий случай, если вкратце – это возможность строить зашифрованные каналы передачи данных между точкой подключения, с которой будет работать пользователь, и облаком. То есть, для того, чтобы зайти в свою среду, пользователь должен будет не только знать свой пароль, он должен будет иметь также право на подключение к VPN-ну. Почему? Потому что перед тем, как заходить на свой удаленный рабочий стол, ему будет необходимо инициализировать VPN-подключение. В зависимости от сложности системы, с которой он работает, это означает либо один раз кликнуть на ярлык, либо выполнить какие-то немного более сложные действия. Чем хорош в этом плане VPN? Во-первых, мы имеем возможность разрешить подключаться к VPN-серверу только с каких-то определенных IP-адресов, во-вторых, мы знаем точно, что данные, передаваемые между пользователями, не попадут в руки, например, его интернет-провайдера.

А интернет-провайдер – это далеко не всегда какой-нибудь оператор связи типа «Аплинк», который занимается собственно связью. Это может оказаться какая-нибудь домашняя сеть, в которой системный администратор Василий хочет сделать что-то «хорошее» для своего соседа по имени Петр – пользователя этой домашней сети. И он может потырить данные этого Петра на ходу, если Петр не использует VPN-подключение.

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

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

Мы рассмотрели основные факторы нарушения безопасности. Конечно же, можно вспомнить еще очень много разных других факторов, например, существует еще так называемая подделка данных. Это уже ближе к области социальной инженерии, но, как вы знаете, каждый из вас может отправить любому человеку письмо с любого е-мейл адреса – это факт, от которого никуда не денешься. Это не является какой-то особой страшной угрозой, но очень часто социальные инженеры очень активно этим пользуются. Конечно, всем известны средства защиты от этого – электронно-цифровая подпись, но кто на самом деле пользуется ею или PGP? Почти никто. Такие факторы были, есть и будут есть, и тут уже не важно, облако это или нет. Подделка тех или иных данных, а также действия социального инженера, который позвонил по телефону или пришел в офис к кому-то и выдал себя за другого человека, действуя с лихостью и напором, очень часто могут увенчаться успехом вне зависимости от того, как устроена IT-инфраструктура предприятия. Но мы немного отклонились от темы безопасности информации.

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

Если говорить о безопасности периметра, то при переходе в облако периметр IT-инфраструктуры, которую необходимо защищать, существенно уменьшается. Почему? Потому что IT-инфраструктура становится менее географически распределенной и занимает меньшую площадь. Как мы все знаем из курса геометрии, чем меньше площадь фигуры, тем меньше ее периметр. Чем меньше наша IT-инфраструктура в географическом плане, тем меньший периметр нам необходимо защищать. Чем меньше компонентов в этой инфраструктуре, тем меньше компонентов нам необходимо защищать. Избавившись от компьютеров (помните, мы говорили несколько минут назад, как системные администраторы не очень любят заниматься безопасностью самих пользовательских компьютеров) мы пересаживаем всех на терминальный сервер. В результате мы получаем заметное сокращение количества систем, которые нам надо защищать. Вместо того, чтобы защищать 20 компьютеров, мы защищаем один терминальный сервер. Вместо того, чтобы защищать пять файловых серверов разных филиалов, мы защищаем один файловый сервер, который находится в облаке в одной и той же локальной сети с терминальным сервером. И так далее. То есть, безопасность периметра значительно легче контролировать за счет того, что он становится гораздо меньше.

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

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

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

Вопрос: Все познавательно и информативно, но есть одно «но». Вы говорили о «наездах» маски-шоу, а как в таких случаях вы гарантируете безопасность данных клиента – «тревожная кнопка» или нечто в этом роде? Или такого нет? 

Ответ: Спасибо за вопрос. В том случае когда необходимо отключить и полностью заблокировать доступ к данным клиента, по заранее согласованной с клиентом процедуре мы это выполняем моментально. Предположим, что у клиента случилось какая-нибудь неприятность. Например, инопланетные захватчики приехали с мигалкой в его офис и говорят: «Отдавай нам свои данные». А клиент рассмеялся им в лицо и говорит: «Ха-ха! Летите обратно на свою планету вместе со своей мигалкой, потому что никаких данных у меня в офисе нет». Но инопланетные заватчики ведь хитрые. Они ведь знаете, как действуют? Они начинают «разговаривать с пользователем разговоры», начинают пугать и говорить:  «Сейчас вам пальцы в дверь будем засовывать и заберем на нашу планету страшную, так что говорите все ваши пароли от десктопов, а то мы сейчас всех вас расстреляем из лазеров». И знаете, пользователи в этом случае могут действительно сдать свои пароли. Винить их в этом, конечно же, не стоит. Поэтому заказчик может предусмотреть это заранее и согласовать с нами процедуру аварийной блокировки. При выполнении процедуры аварийной блокировки мы полностью отключаем весь сетевой трафик между инфраструктурой пользователя и внешним миром. До подачи пользователем заявления о том, что необходимо разблокировать сетевой трафик, он будет полностью запрещен. И даже если пользователи этого предприятия захотят поделиться с инопланетянами, это уже ни к чем не приведет. И это очень важно.

Вопрос: Скажите, пожалуйста, что с DDoS-атаками в облаке? Oно, получается, публичное и его можно атаковать? А классическая IT-среда остается закрытой и на нее проблематично провести DDoS?

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

Вопрос: Я читал в одной из статей, что зарубежные провайдеры никак не отслеживают DDoS, а поэтому выставляют клиенту счета за трафик, который был «вражеским».

Ответ: Знаете, честно говоря, это все равно как не отреагировать на какую-то проблему клиента и потом выставить ему счет за то, что он, пока эта проблема не была решена, потреблял какие-то ресурсы. Так действительно бывает в тех случаях, когда провайдер слишком крупный для того, чтобы его вообще не волновало, что там у этих клиентов происходит. Компания «Аплинк» работает с 2005 года и сколько бы мы ни росли, нас всегда волнует, что происходит у клиента. И если речь идет о распределенной DDoS-атаке, мы не станем заставлять клиента платить за трафик. Более того, еще один интересныый момент: трафик-то у нас в тарифных планах не учитывается. Спасибо что задали этот вопрос и заодно я напомнил о том, что мы не считаем трафик, в отличие от крупных зарубежных провайдеров.

Вопрос: Как быстро вы отключаете доступ? Полчаса, час?

Ответ: Заявлено, если я не ошибаюсь, максимум 3 часа, но всегда отключаем за 5 минут. Заявленные 3 часа – это тот максимум, на который мы действительно даем гарантию, что в случае если даже процедура будет выполнена как-то неправильно, и нам ее придется пересогласовывать с клиентом и т.п. Но вообще на учениях мы это делали за 5 минут. Да, голосовой звонок с определенного номера – это как вариант. Процедуры с каждым клиентом согласовываются индивидуально, потому что для некоторых удобнее отправить SMS, для некоторых – сделать звонок, для некоторых – «дернуть за веревочку», и так далоее. Пока что, скажу честно, это делалось только на учениях. Реально еще не приходилось экстренно отключать ничьи ресурсы.

Вопрос. А можно немного подробнее о контроле пользователя в облаке?

Ответ: Да, конечно. Мы являемся партнерам компании Yaware, которая делает свой собственный продукт, он так и называется – Yaware, который позволяет руководителю и службе безопасности  предприятия отслеживать, во-первых, статистику работы пользователей, то есть, сколько часов пользователь потратил на работу в MS Excel с каким-то файлом, сколько – на просмотр VK.com или на что-то еще. Но кроме статистического анализа эта система помогает также обеспечить более плотный контроль над действиями пользователя – те же снимки рабочих столов и т.п. Сейчас мы ведем переговоры также с компанией «Атом Безопасность», которая выпускает систему StaffCop. Это аналогичная система, но у нее несколько иной набор функций, они очень похожи и обе чертовски хороши – Yaware и StaffCop. Эти две системы я бы рекомендовал использовать всегда и везде. Более того, они работают не только в облаке, но и в классической инфраструктуре, но в облаке они зарекомендовали себя просто великолепно.

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

Ответ: Понял ваш вопрос. Наверняка здесь важно заметить одну вещь. В том-то все и дело, что при полной миграции в облако никакая информация вообще не сохраняется на устройство пользователя. Устройство, с которого подключается пользователь, может вообще не иметь жесткого диска, он совершенно не нужен. В том случае если пользователь заходит с системы терминального доступа, вся та информация, с которой он работает, остается в облаке. Она скачивается временно на это устройство. Соответственно, она полностью защищена и, как уже говорилось, мы рекомендуем обеспечивать к ней доступ только из авторизованных источников, то есть, например, можно сделать так, что доступ к ней будет только из офиса. Почему? Потому что только из офиса будет разрешено установить одно единственное VPN-соединение, через которое будут идти все пользователи локальной сети. А другое VPN-соединение система уже не разрешит. И пользователь уже не сможет подключиться с домашнего компьютера, на котором его сын установил какую-то фигню. Защиту в облаке гораздо проще обеспечить, чем защиту своей обычной инфраструктуры, она проще для администрирования и управления, поскольку она меньше. Чем меньше периметр, как мы с вами говорили, тем меньше гемора по его защите. Поэтому даже если у пользователя уведут пароль, все равно не смогут зайти в его инфраструктуру, потому что пользователь будет работать только из офиса, только по VPN-ну, который является единственным разрешенным соединением. Это уже своего рода двухфакторная авторизация. Помимо пароля, мы еще привязываемся к VPN-ну. Можно сделать трехфакторную, четырехфакторную и так далее. То есть, усложнить доступ можно всегда. Если мы имеем малый периметр, мы можем защитить его, замуровать в стенку, забетонировать и оставить торчать наружу только маленькую воронку, через которую пользователи могут попадать в систему.

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

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

Вопрос: Я правильно понимаю, что «тревожная кнопка» может быть и не у админа, а у начальника СБ или директора?

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

Вопрос: Это бесплатная опция – эта кнопка?

Ответ: Так точно, это бесплатная опция, эта процедура естественна и мы не взимаем за нее деньги. А зачем? Тем более, что мы надеемся, что клиент ею вообще никогда не воспользуется.

Вопрос: Это хорошо, что есть разграничение прав. А объемы ресурсов могут распределяться? Например, Админ-1 получает свой объем, а Админ-2 получает свой кусочек облака?

Ответ: Да, можно устанавливать некоторые квоты. Например, количество виртуальных машин (ВМ). Мы можем задать Админу-1, что он имеет право создать три ВМ и три ЖД. Но мы не можем пока еще задать ему объем этих ЖД. Но количественные показатели – количество ВМ, ЖД, снепшотов и еще кое-какие мелочи мы можем задавать и регулировать. Предположим, что корневой пользователь облака не имеет ограничений, а администраторы, работающие под его началом, имеют ограничения по количеству ВМ.

Вопрос: Защита копий осуществляется кем и чем? Шифруются ли они вами или с помощью ключей организации ее владельцами? Вопрос издалека: паяльник может быть воткнут не только в сотрудника компании, но и в сотрудника «Аплинк».

Ответ: Защита копий осуществляется следующим образом. Сама по себе резервная копия не шифруется. Но мы очень настоятельно рекомендуем использовать на виртуальных дисках зашифрованные разделы. Чтобы мы даже при большом желании не смогли получить доступ к информации клиента, мы рекомендуем, помимо шифрования каналов, использовать также драйвера программного шифрования диска. При этом вся информация или какой-то раздел на нем делается зашифрованным и никогда не расшифровывается. Его расшифровка происходит только на уровне драйвера внутри оперативной памяти этой машины. Поэтому даже если мы очень захотим по какой-либо причине получить данные нашего клиента, мы не сможем этого сделать. Почему? Потому что драйверу при загрузке операционной системы сисадмин клиента вводит ключ и драйвер только просле этого начинает «на лету» расшифровывать данные. Это не встроенный инструментарий, в Винде, например, это делают прикладные дополнительные софтины, а в Линуксе – это встроенный инструментарий, который называется cryptor file system. Так или иначе, средства для этого есть и, как говорится, в борьбе с утечкой информации все средства хороши. Единственное, что хочу сказать, что использование шифрованной файловой системы на дисках, с которыми ведется интенсивный обмен, тянет за собой необходимость иногда увеличивать количество ядер процессоров.

Спасибо всем, кто присутствовал и задавал вопросы, на этом мы прощаемся до следующей среды, 20 марта.

---