Файл: Облачные сервисы (Характеристика «облачных» хранилищ данных).pdf

Как и в Dropbox, можно ограничивать использование канала связи, однако лимитировать в SugarSync разрешается лишь Upload.

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

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

2.4 Безопасно ли хранить файлы в «облаке?»

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

Миф 1. «Облака» небезопасны. Третьи лица могут вмешаться в процесс.

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

Давайте поймем, кто такие третьи лица, и какие угрозы возникают с их стороны, на примере бухгалтерской информационной системы.

Как правило, информационным системам бизнеса угрожают с трех направлений: конкуренты, некие «органы» и собственные сотрудники.

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

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

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

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

Каналы связи и питание в дата-центрах задублированы.

Хакерские атаки, – что есть то есть. На слуху периодические DDOS-атаки на известные ДЦ. Но, как правило, они вызывают лишь временную недоступность сервиса, но никак не кражу данных. Взломать же многоуровневую программную защиту данных в «облаке», наняв команду профессиональных хакеров, достаточно дорого. Гораздо дешевле подкупить одного из сотрудников, который передаст логины-пароли или вообще всю базу конкурентам. И вот здесь мы подходим к социальной угрозе.

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

Перед пресловутым человеческим фактором не устоят ни «облако», ни настольные системы.

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

Миф 2. Российские «облачные» проекты слабоваты в рамках мировой конкуренции. На Западе большой спрос, но наши проекты просто не дотягивают до их уровня.

Не все так плачевно, и «облачные» решения, разработанные в России, пользуются успехом на мировой арене. Просто в общей массе мы пришли на рынок позднее Запада, и пока еще учимся продавать. Все еще впереди.

Я думаю, проблема в неумении российских производителей (в том числе программного обеспечения) продавать. Например, наши выпустят гениальную, без преувеличения, вещь, и рассказывают о ее преимуществах. На Западе же рассказывают не о преимуществах продукта, а про радость покупателя от обладания этим продуктом. Грубо говоря, наши говорят «смотрите, какой вкусный я испек торт», западные – «смотрите, какими довольными вы будете, если съедите этот торт».

Миф 3. «Облачные» технологии разрабатываются с прицелом на крупные предприятия и не рассчитаны на малый бизнес.

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

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

Миф 4. Предпринимателю не обязательно покупать облачный бухгалтерский сервис , т.к можно самому вести бухучет “на коленке”.

Если бы все было просто, у автоматизаторов бухгалтерии не было бы работы. Это радость, т.к. я автоматизатор бухгалтерии.

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

Что еще могу отметить:

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

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

Проработал квартал - добро пожаловать в отчетный период. В каждый из этих органов нужно отчитаться, при этом нет единого стандарта и даже принципа построения отчетности. У каждого органа, я имею в виду ИФНС, ПФР, ФСС и статистику, свои правила построения отчетности. При этом логика прослеживается только у налоговой. Разные отчеты в налоговую строятся по одинаковым принципам. Чего не скажешь об отчетности в ПФР и ФСС.

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

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

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

В общем, России еще есть куда развиваться. И я верю что именно автоматизаторы бухгалтерии, такие как мы в Небе, способны что- то поменять. Главное, хотеть этого, а не мечтать "сбежать из этой страны".

2.5 Определение шлюза облачного хранилища данных

Перед продолжением давайте вернемся немного назад и постараемся ответить на главный вопрос – что такое шлюз облачного хранилища данных? Доступ к облачным сервисам типа хранилища данных осуществляется по сети, публичной или частной. Тип облачного сервиса, к которому необходимо получить доступ (рис. 1) будет определять, что вам нужно. Так, к одним сервисам можно получить доступ с помощью обычного веб-браузера, в то время как для доступа к другим сервисам могут требоваться съемные модули. Для доступа к одним облачным сервисам или ресурсам может требоваться загрузка приложения, агента или другого инструментального средства, тогда как для доступа к другим сервисам может требоваться устанавливаемое на территории предприятия устройство или шлюз.

ПО и шлюзы или устройства облачного доступа применяются для обеспечения доступа к облачным хранилищам данных локальных приложений. Шлюзы, помимо обеспечения облачного доступа, предоставляют функции репликации, snapshot и другие функциональные возможности сервиса хранения данных. Облачные шлюзы или серверное ПО включают инструменты от BAE, Citrix, Gladinet, Mezeo, Nasuni, Openstack, Twinstrata и Zadara. Кроме облачных шлюзов или облачных точек присутствия (cpops), доступ к публичным сервисам также поддерживается с помощью разных программных инструментов. Многие инструментальные средства защиты информации, в том числе резервирование/восстановление, архивирование, репликация и другие функции, включают или планируют включить поддержку доступа к разным публичным сервисам, таким как Amazon, Google, Iron Mountain, Microsoft, Nirvanix или Rackspace.

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

Например, я могу использовать базовые функции своих учетных записей в системах хранения данных Amazon S3 или Rackspace с помощью их веб-инструментов и других предоставленных инструментальных средств. Однако для выполнения резервного копирования и восстановления я использую инструментальные средства, предоставляемые сервисным провайдером, и я имею дело с двумя разными сервисами облачных систем хранения данных. Этот инструмент представляет собой интерфейс для определения того, что необходимо резервировать, защищать и восстанавливать, а также разрешения общих (публичных или частных) устройств хранения данных и сетевых дисков. Кроме предоставления интерфейса (Рис. 2), этот инструмент также использует специфические API и протоколы других сервисов, включая функции PUT (создать или обновить контейнер), POST (обновить заголовок или мета данные), LIST (извлечь информацию), HEAD (доступ к мета данным), GET (извлечь данные из контейнера) и DELETE (удалить контейнер). Обратите внимание на то, что реальное поведение и функциональные возможности API будут зависеть от сервисного провайдера. Важность приведенного выше примера состоит в том, что когда вы знакомитесь с провайдерами облачных систем хранения данных, вам могут встречаться упоминания операций PUT, POST, LIST, HEAD, GET и DELETE, а также таких сервисов как пропускная способность и доступность. Некоторые сервисы могут включать неограниченное число операций, тогда как другие сервисы могут брать дополнительную плату за выполнение обновлений, листинг или извлечение ваших данных. Зная такие базовые облачные функции как PUT или POST и GET или LIST, можно получить лучшее представление о том для чего они используются, а также о том какую роль они играют в оценке разных сервисов, ценообразовании и тарифных планах.

В зависимости от типа облачного сервиса, могут использоваться разнообразные протоколы или интерфейсы, в том числе iSCSI, NAS NFS, HTTP или HTTPs, FTP, REST, SOAP, Bit Torrent, API и платформа PaaS, включающая поддержку.NET или набор команд SQL, в дополнение к XM, JSON или другим форматам данных. Виртуальные машины (VM) можно перемещать в облачный сервис с использованием функций передачи файлов или возможностей провайдера по загрузке образов виртуальных машин. Например, такие VM как VMDK или VHD подготавливается локально в вашей среде, а затем передаются провайдеру для выполнения. Облачные сервисы могут давать программу или утилиту для доступа, которая позволяет вам определять время, место и метод защиты данных, по аналогии с другими средствами резервного копирования или архивирования.