Pull to refresh

Comments 8

Аутентификация: если для доступа к сервису сотрудник использует свой корпоративный логин и пароль, злоумышленник может подобрать его и использовать для доступа к другим более опасным сервисам. Или, в самом простом случае, заблокировать учётную запись, исчерпав число неверных попыток ввода пароля.В случае, если имена учётных записей генерируются последовательно по некому алгоритму (login001, login002...), заблокировать можно не только жертву, но и все подобранные логины.

Обычно это решается RADIUS аутентификацией вместо AD аутентификации, хотя логин и пароль используются те же. Перебор логинов и паролей заблокирует на какое-то настраиваемое время вход логина через сервис, но не логин/аккаунт в-целом.
Если честно, то я больше верю в безопасность своих приватных репозиторев на github и учётке в Google нежели местной инфраструктуре поднятой админами, которые не смогли устроиться в Google. Это просто субъективное впечатление. Я не прав?
Да, я тоже больше верю в безопасность Google. Если для большой компании администрирование сервисов не является источником дохода (а это скорее всего так), то логичным выглядит передача этой функции на аутсорс. Особенно, такой удобный, как Google, GitHub или Slack.
Но часто в дело вмешивается служба безопасности и наше законодательство, боящиеся хранить «стратегическую» информацию у «вражеских» компаний. Особенно, если их дата-центры находятся за пределами России. Поэтому, вариантов не остаётся, к сожалению.

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


Технически же, любой адекватный админ будет за Google Apps, поскольку это существенное упрощение работы.

А могли бы поделиться ссылкой кого забанил Google по доносу конкурентов? Спасибо.
Любой информация которая находится на сторонних сервисах, это не ваша информация и с ней могут делать что хотят и как хотят, Яблочная компания считает, что все у вас в аренде и покупки это не покупки а аренда.
В любой момент вы можете получить письмо, в лучшем случае, с заголовком I'm sorry, but… или просто недоступный сервер, с сообщением что вам была выслана абуза и вы на нее не прореагировали… Но в основном, получаете пустой сервер (переписку, отсутствующий аккаунт)
В лицензионных соглашениях сказано, что ни кто не за что не отвечает и не обещает. Поэтому и приходиться поднимать свою инфраструктуру, что бы как то контролировать информацию.
qwertyRu Хотелось бы узнать в таком случае как вы трактуете соглашение об использовании сервисов Google
https://gsuite.google.com/intl/ru/terms/2013/1/premier_terms.html

7. Права на объекты интеллектуальной собственности; торговые марки

7.1. Права на объекты интеллектуальной собственности. За исключением явно перечисленных здесь случаев, настоящее Соглашение не предоставляет ни одной из сторон никаких подразумеваемых или иных прав на контент другой стороны или на ее интеллектуальную собственность. По соглашению сторон Клиенту принадлежат все Права на объекты интеллектуальной собственности в отношении его данных, а компании Google принадлежат Права на объекты интеллектуальной собственности в отношении Служб.
PACBET
Это про право на интеллектуальную собственность. Общая фраза, что ваше это ваше (ради интереса, вы можете доказать что данные это действительно ваши данные?), а наше это наше. Но если поступает жалоба что чьи-то авторские права, по его мнению нарушены, то сервису проще временно ограничить доступ, а клиенты пусть сами разбираются, кто и что друг-другу должен.
+ соглашение может меняться в любой момент в любую сторону.
Sign up to leave a comment.

Articles