Не отрицая национальных особенностей, можно утверждать, что в нашей стране есть живые примеры, когда разработку выводят в облака, и их – немало. Если вы внимательно читали пост, то, наверное, заметили, что из 3 серверов с разными ролями мы допустили перевод в облако только разработки… поэтому рассматриваемый пример — вполне себе жизненный.
Но если уж зарываться в тему отношения к хранению критичной информации, как сдерживающего фактора для активного использования облачных решений, то со стороны операторов уже есть предложения сервисов, соответствующих по защите требованиям ФСТЭК и ФСБ. А при реализации должных мер защиты на уровне СУБД/серверов приложений, их расположение становится непринципиальным. Другое дело, что под такой сценарий программный стек должен проектироваться изначально. И поэтому мы пока предлагаем посчитать только машину разработчика/тестировщика. Остальное требует более детальной оценки.
Позвольте с вами не согласиться. Сопровождение зоопарка железа, сервисные контракты, ЗИП, инфраструктурное ПО, резервное копирование – весь этот слой и сопутствующая головная боль передаются (не безвозмездно) сервис-провайдеру. Кроме того, на местах, как правило, наблюдаются низкие зарплаты и высокая текучка кадров, особенно, если таковые действительно оказываются квалифицированы. То есть затраты на обучение оказываются постоянными. Кроме этого требования к информационной безопасности могут сопровождаться проверками соответствия этим требованиям. А это значит, что понадобятся существенные вложения в собственную инфраструктуру, в персонал. На этом фоне при использовании типичных консолей облачных сервисов, сопровождение оказывается более-менее тривиальным и требует минимального времени на освоение.
Как упоминалось в посте, наш расчёт очень «сфероконичен». Это только пример. Можно посчитать процессорное время по тем же нормативам, что и дисковое пространство, накинуть время для загрузки данных, например, если из творческого порыва их вдруг захочется не генерить скриптом, а заливать все два-три терабайта каждый раз. Но даже при этом стоимость облака останется более привлекательной в сравнении с железкой.
Но ведь и ситуация, когда под задачу требуется один хост без обвязки, по нынешним временам скорее атипична, поэтому в реальности, скорее-всего, расчет будет посложней (как минимум, может потребоваться vpn в контур разработки). В случае построения частного/гибридного облака затраты для большинства сценариев будут отличаться в большую сторону, по сравнению с облаком публичным, и не факт, что будут оправданы для одной ВМ. А с точки зрения квалификации персонала на внедрение и сопровождение, если рассматривать вариант с частным облаком на инфраструктуре сервис-провайдера, то планка требований может оказаться заметно ниже, чем при организации и сопровождении эквивалентной инфраструктуры на своих мощностях.
Конечно, сложно не согласиться с тем, что при оценке возможности использования облачных решений следует рассматривать все их грани с учётом характерных им особенностей. Но мы не ставили задачу посчитать все «от и до». Мы хотели показать, как быстро прикинуть стоимость одного сервиса – для собственного понимания или для аргументации руководству.
Нет, мы не говорим, что этот пост — руководство к действию :) Мы предлагаем задуматься, а не просто использовать калькулятор Amazon. Речь идет о том, чтобы задействовать дополнительный ресурс или хотя бы учитывать его, если не в построении инфраструктуры, то по крайней мере для её диверсификации.
Почему выбрали пример на AWS? Просто потому что этот вариант доступен и для него есть готовый калькулятор. Но даже с AWS облако бывает куда выгоднее. Для конкретных задач, конечно, нужно проводить расчеты с рядом потенциальных поставщиков сервиса. AWS в данном случае, так – первая прикидка.
В специализированных устройствах, разумеется, есть возможность получения биометрических образцов более высокого качества, нежели в мобильных устройствах. Но и последних достаточно для мультимодальной аутентификации пользователя в информационных системах.
Тут, увы, мы не можем согласиться. Кто сказал, что авторизация по сетчатке более надежна, чем дактилоскопия? Возьмите хотя бы случай с обманом системы Samsung, который повелся на распечатанный рисунок сетчатки? Если говорить о биометрии, качество реализации систем зависит от многих факторов, но ни одна из них не может гарантировать 100% точной аутентификации. Самый лучший выход – использование комплексных систем авторизации. То есть мы предлагаем внедрять биометрию в дополнение к другой системе или со считыванием ряда параметров (пальцы, ладонь, сетчатка, голос), но не как единственный метод защиты и контроля доступа.
Наша практика подтверждает, что авторизация по одному только отпечатку пальца иногда оказывается недостаточно точной. При этом внесение в базу отпечатков нескольких пальцев дает качественное повышение точности. Более того, если вы используете дактилоскопические сенсоры, существует хорошая практика считывания рисунка вен с ладони. Например, как на этом проекте. Приложив ладонь, сотрудники BurgerKing авторизуются в системе – тем самым обеспечивается учет рабочего времени сотрудников. Такой подход позволяет упростить биометрическую аутентификацию людей рабочих специальностей (уборщики, инженеры, грузчики, монтажники, повара), у которых могут быть грязные или поврежденные рисунки на пальцах.
Но если уж зарываться в тему отношения к хранению критичной информации, как сдерживающего фактора для активного использования облачных решений, то со стороны операторов уже есть предложения сервисов, соответствующих по защите требованиям ФСТЭК и ФСБ. А при реализации должных мер защиты на уровне СУБД/серверов приложений, их расположение становится непринципиальным. Другое дело, что под такой сценарий программный стек должен проектироваться изначально. И поэтому мы пока предлагаем посчитать только машину разработчика/тестировщика. Остальное требует более детальной оценки.
Но ведь и ситуация, когда под задачу требуется один хост без обвязки, по нынешним временам скорее атипична, поэтому в реальности, скорее-всего, расчет будет посложней (как минимум, может потребоваться vpn в контур разработки). В случае построения частного/гибридного облака затраты для большинства сценариев будут отличаться в большую сторону, по сравнению с облаком публичным, и не факт, что будут оправданы для одной ВМ. А с точки зрения квалификации персонала на внедрение и сопровождение, если рассматривать вариант с частным облаком на инфраструктуре сервис-провайдера, то планка требований может оказаться заметно ниже, чем при организации и сопровождении эквивалентной инфраструктуры на своих мощностях.
Конечно, сложно не согласиться с тем, что при оценке возможности использования облачных решений следует рассматривать все их грани с учётом характерных им особенностей. Но мы не ставили задачу посчитать все «от и до». Мы хотели показать, как быстро прикинуть стоимость одного сервиса – для собственного понимания или для аргументации руководству.
Почему выбрали пример на AWS? Просто потому что этот вариант доступен и для него есть готовый калькулятор. Но даже с AWS облако бывает куда выгоднее. Для конкретных задач, конечно, нужно проводить расчеты с рядом потенциальных поставщиков сервиса. AWS в данном случае, так – первая прикидка.