Перейти к содержанию

Google запускает облачный сервис хранения данных

arh_lelik1

Автор arh_lelik1
в Новости и события со всего мира

 Поделиться

Рекомендуемые сообщения

arh_lelik1

arh_lelik1

Опубликовано
Опубликовано

Компания Google планирует в скором времени запустить собственное файлохранилище под названием Google Storage. Сервис станет прямым конкурентом службы S3 от Amazon, но будет в первую очередь ориентирован на веб-разработчиков.

 

Компания Google на своей конференции для разработчиков Google I/O, которая проходит в Сан-Франциско 19 и 20 мая, планирует представить новый облачный сервис для хранения данных под названием Google Storage for Developers.

 

Как отмечают аналитики, Google Storage станет прямым конкурентом целого ряда подобных сервисов от других компаний, таких как Amazon S3, однако будет ориентирован в первую очередь именно на веб-разработчиков.

 

Сейчас интернет-гигант уже предлагает пользователям файлохранилище в рамках своего сервиса электронной почты Gmail, однако в нем сильно ограничен размер файлов - сейчас он составляет 1 ГБ (с возможностью доплаты по 25 центов в год за каждый дополнительный гигабайт), а максимальный размер любого загруженного файла не должен превышать 250 МБ. При этом, лишь недавно были сняты ограничения со списком допустимых форматов файлов для хранения.

 

Как сообщает TechCrunch, Google Storage for Developers будет предоставлять пользователям более безопасное, стабильное и защищенное решение для облачного хранения данных и совместной работы над ними. Известно, что веб-разработчики смогут хранить на сервисе файлы размером до 50 ГБ и получать к ним доступ из любых мест при наличии связи с Сетью.

 

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

 

Еще одним преимуществом Google Storage for Developers будет тот факт, что данные пользователей будут дублироваться и распределяться по различным местам в разных дата-центрах по всей территории США. Таким образом, выход из строя какого-либо одного сервера или даже всего дата-центра не сможет значительным образом повлиять на доступность и целостность данных.

 

Известно, что Google готовится к серьезной конкуренции с Amazon и другими провайдерами аналогичных услуг на рынке облачного хранения данных. Так, в Google Storage for Developers будет присутствовать удобный функционал для перехода с Amazon S3 на данный сервис. Google Storage for Developers будет поддерживать программный интерфейс REST API, а разработчики смогут управлять своими данными как посредством командной строки, так и через стандартный веб-интерфейс.

 

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

Пожалуйста, войдите, чтобы комментировать

Вы сможете оставить комментарий после входа в



Войти
 Поделиться
Перейти к списку тем

  • Похожий контент

    • KL FC Bot
      Что не так с SSO в облачных сервисах и как снизить риски
      Автор KL FC Bot
      Утечки учетных данных остаются одним из самых популярных у злоумышленников способов проникновения в организацию. Только за 9 месяцев 2023 года по данным Kaspersky Digital Footprint Intelligence в даркнете было опубликовано 315 миллионов записей учетных данных, среди которых множество реквизитов доступа к корпоративным ресурсам, в том числе и к ресурсам компаний из списка Fortune 500.  Чтобы эффективнее управлять связанными с этим рисками, минимизировать число уязвимых аккаунтов, быстрее замечать и пресекать несанкционированный доступ, компании внедряют системы управления identity, о которых мы подробно писали ранее. Но эффективный процесс управления identity невозможен, пока большинство корпоративных систем не поддерживают процедуру унифицированной аутентификации. Для внутренних систем компании она обычно завязана на централизованный каталог, например Active Directory, а во внешних SaaS-системах взаимодействие с корпоративным каталогом identity ведется через платформу Single Sign-on (SSO) —либо внешнюю, либо развернутую в инфраструктуре компании, такую как ADFS.
      Для сотрудников это предельно удобно — логинясь во внешние системы, такие как SalesForce или Concur, сотрудник проходит единый для корпоративной сети процесс аутентификации, включая ввод пароля и предъявление второго фактора (кода OTP, USB-токена и так далее, согласно корпоративной политике), ему не нужны никакие дополнительные логины и пароли. Более того, однократно войдя утром в одну из систем, в остальные можно входить автоматически. Помимо удобства этот процесс в теории безопасен, поскольку службы IT и ИБ имеют полный централизованный контроль над учетными записями, парольными политиками, методами МФА и логами.
      Но на практике уровень безопасности внешних систем, поддерживающих SSO, зачастую оказывается не таким уж высоким.
       
      Подводные камни Single Sign-On
      Пока пользователь входит в SaaS-систему, сервер этой системы, клиентское устройство пользователя и платформа SSO проходят несколько этапов взаимодействия, в которых платформа SSO проверяет пользователя и выдает SaaS-системе и клиентскому устройству токены аутентификации, которые подтверждают права пользователя. При этом платформа может снабжать токен целым рядом параметров, напрямую влияющих на безопасность. Они могут включать:
      указание периода действия токена (и сессии), по истечении которого потребуется повторная аутентификация; привязка токена к конкретному браузеру или мобильному устройству; привязка токена к конкретным IP-адресам или IP-диапазонам, что позволяет реализовать в том числе географические ограничения; дополнительные условия окончания сессии, например закрытие браузера или выход пользователя из самой SSO-платформы. Ключевая проблема заключается в том, что некоторые облачные провайдеры неверно интерпретируют или вовсе игнорируют эти ограничения, нарушая таким образом модель безопасности, которую выстроила команда ИБ. Более того, в ряде случаев SaaS-платформы недостаточно контролируют корректность самих токенов, открывая простор для их подделки.
       
      Посмотреть статью полностью
    • rupitsa
      Правильное хранение лицензий!
      Автор rupitsa
      Всем доброго времени! Возник вопрос по правильному хранению лицензий! Я почему то думал, что могу добавить ключ на my Kaspersky, и пока я не добавлю ни одного устройства, у меня ключ будет там в целости и сохранности, а оказалось все и на оборот, таким способом я уже потерял ключ от KSC, что очень жаль.
       Чтоб больше не возникло вопросов по их хранению, можно ли вообще их как то хранить на портале или нет?
       
    • Валерий Шарыкин
      VPN сервисы
      Автор Валерий Шарыкин
      Все ли VPN сервисы запрещены? 
       
      Сообщение от модератора Mark D. Pearlstone Тема перемещена из раздела "Технический раздел".
    • KL FC Bot
      Новые требования к надежности и хранению паролей
      Автор KL FC Bot
      Требования, которые онлайн-сервисы предъявляют при проверке своих пользователей, — будь то длина пароля, обязательное указание номера телефона или необходимость биометрической проверки с подмигиванием, зачастую регулируются индустриальными стандартами. Одним из важнейших документов в этой сфере является NIST SP 800-63, Digital Identity Guidelines, разработанный Национальным институтом стандартов и технологий США. Требования этого стандарта обязательны для выполнения всеми государственными органами страны и всеми их подрядчиками, но на практике это означает, что их выполняют все крупнейшие IT-компании и действие требований ощущается далеко за пределами США.
      Даже организациям, которые не обязаны выполнять требования NIST SP 800-63, стоит глубоко ознакомиться с его обновленными требованиями, поскольку они зачастую берутся за основу регуляторами в других странах и индустриях. Более того, свежий документ, прошедший четыре раунда публичных правок с индустриальными экспертами, отражает современный взгляд на процессы идентификации и аутентификации, включая требования к безопасности и конфиденциальности, и с учетом возможного распределенного (федеративного) подхода к этим процессам. Стандарт практичен и учитывает человеческий фактор — то, как пользователи реагируют на те или иные требования к аутентификации.
      В новой редакции стандарта формализованы понятия и описаны требования к:
      passkeys (в стандарте названы syncable authenticators); аутентификации, устойчивой к фишингу; пользовательским хранилищам паролей и доступов — кошелькам (attribute bundles); регулярной реаутентификации; сессионным токенам. Итак, как нужно аутентифицировать пользователей в 2024 году?
      Аутентификация по паролю
      Стандарт описывает три уровня гарантий (Authentication Assurance Level, AAL), где AAL1 соответствует самым слабым ограничениям и минимальной уверенности в том, что входящий в систему пользователь — тот, за кого себя выдает. Уровень AAL3 дает самые сильные гарантии и требует более строгой аутентификации. Только на уровне AAL1 допустим единственный фактор аутентификации, например просто пароль.
       
      View the full article
    • Самогонщик
      Сервис заказа такси
      Автор Самогонщик
      В данный момент держу на телефоне 4 программы для заказа такси. С утра при поездки на работу выбираю самый дешевый вариант или кто быстрее приедет бывает что за 100 руб. не кто не едить когда у Яндекса цена около 200 руб.

×
×
  • Создать...