Проблемы в корпоративном использовании SAAS

Итак, поддавшись новомодным веяниям, малые и большие компании начинают, кто несмело, кто резво и решительно подписываться на разнообразные сервисы.

Первоначальная эйфория и «Ухты!»-эффект проходят.

А в будни мы получаем проблемы, о которых ранее не особо и задумывались…

Из нашего опыта, типичный комплект некой абстрактной компании состоит из приложений следующих групп:

• почтовой службы
• CRM
• бухгалтерии
• документооборота
• связь (голосовые и видеоконференции)
• антивирус по-подписке
• корпоративная база знаний (хранилище инструкций, методичек)

Пользуется такими сервисами обычно от 12 и более человек штатных работников.

Каждому работнику теперь необходимо придумывать и запоминать от 3х до 7и (по числу сервисов в компании) новых, многосимвольных и уникальных пароля. А потом регулярно их менять.

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

Все ли могут помнить разные длинные бессмысленные наборы символов?

2. Стой! Кто идёт?

Так как учетные записи к публичным сервисам находятся вне контроля компании, то получить доступ к корпоративной информации может любой человек, который так или иначе заполучил пароль вашего сотрудника. Если вернуться к проблеме №1 — то вы понимаете, что это делается просто элементарными методами «социальной» инженерии.

Хорошее решение — применение на сервисах принципов двухфакторной аутентификации — когда, кроме пароля, человеку необходимо подтвердить свою персону еще неким личным техническим устройством.
Самые популярные способы:

• одноразовые коды, высылаемые на личный мобильный телефон человека через SMS
• одноразовые коды на личных электронных брелоках
• одноразовые коды на мобильных устройствах
• одноразовые коды на скретч-картах
• использование сертификатов на электронных токенах

Однако, слишком мало сервисов, которые используют двухфакторную аутентификацию!

Ещё одна проблема по причине того, что вы не контролируете сервисы — вы не можете своим сотрудникам ограничить доступ к корпоративной информации во времени и пространстве.
С одной стороны:

• прекрасная гибкость в работе сотрудников!
• офис перестаёт быть клеткой!
• можно выполнять свою работу, находясь в интернет-кафе на другом конце планеты!

А если у вашего сотрудника похитили пароль или его ноутбук? И теперь на другом конце планеты находится злоумышленник!
Возможность пользоваться внешними сервисами где-угодно превращается в проблему.

Это точно ваш бухгалтер осуществил платёж?

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

Такой неловкий момент, когда вы не успели удалить учётную запись сотрудника в сервисе документооборота и проекты ваших контрактов ушли к конкурентам.

Во многих средних и крупных компаниях уже ведётся управление сотрудниками через каталоги Active Directory или LDAP.
Но редкие публичные сервисы способны синхронизировать своё информационное поле с корпоративными каталогами «на-лету».

Придётся теперь всё дублировать вручную в КАЖДОМ(!) новом сервисе.

А используют ли приобретённые вами сервисы технологию «сквозной» Windows-аутентификации, в которой пользователю достаточно только авторизоваться в Windows-домене?

Нет Windows-аутентификации!

Если компания уже давно выросла, имеет разветвлённую структуру филиалов или крупных дивизионов, то иногда возникает необходимость:

• приобретать сервисы централизованно
• распределять сервисы по разным дивизионам
• передать распределение учётных записей на сервисы под контроль администраторов дивизионов

В такой ситуации перед корпоративной IT-службой возникают дополнительные трудности.

— Делегирование??!
— Не, не слышали.

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

• Адреса и банковские реквизиты ваших партнёров или список товарной номенклатуры. Их необходимо дублировать, как в бухгалтерской системе, так и в CRM.
• Контракты, согласованные и зафиксированные в СЭД так же скорее всего необходимо продублировать в CRM.

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

Все эти проблемы мы увидели и прочувствовали на своём опыте за 3 года работы в проекте Softcloud.ru.
И в результате обсуждений и родились требования к новому SAAS-инструменту, который предоставит возможность:

• использовать идеологию единой точки входа (SSO)
• иметь, но не запоминать множество длинных и сложных паролей
• использовать многофакторную аутентификацию в виде:
  • одноразовых персональных кодов, передаваемые в виде SMS
  • одноразовых персональных кодов, передаваемые через е-mail
  • применения электронных USB-токенов
• работать, как со стационарных компьютеров, так и с персональных мобильных устройств
• контролировать место и время использования корпоративными сервисами
• работать в единой точке администрирования учётными записями
• использовать Windows-аутентификацию во внешние сервисы
• управлять подписками на внешние сервисы из одной точки
• обеспечить возможность делегирования управления сервисами
• обеспечить отчётность об использовании всех сервисов вашими сотрудниками
• объединить существующие приложения в единый каталог, чтобы пользователи могли в одном месте почитать их описания и сравнить декларируемые возможности
• в перспективе обеспечить синхронизацию заданной информации между различными сервисами
• примененять инструмент как в публичном, так и закрытом режиме (Public/Private Cloud)

Автор: gis

Источник