Журнал о системах электронного документооборота (СЭД)

Последние комментарии :

Алиса Муратова 02 октября 2017 г. 11:12  

Вадим, я говорила в целом о том, что любые нововведения вызывают недоверие. Не стоять же теперь на месте из-за эдакого страха перемен.

А в целом да, с вашим высказыванием согласна. Мысль, возможно, не совсем логично построена :)

Вадим Майшев 02 октября 2017 г. 09:46  
Судя по практике, если на федеральном уровне принимают решение о переводе документов в электронный вид, то вопросы защиты персональных данных прорабатываются должным образом. Вспомните, как в свое время реагировали на нововведения пользователи сервисов ЭДО? Многие не доверяли ни электронным счетам-фактурам, ни операторам. Время показало - зря

:-) Электронные счета-фактуры не содержат персональные данные, а операторы ЭДО СФ не обеспечивают обработку такой информации!

Алена Ускова 26 сентября 2017 г. 13:14  

Вроде бы, суд редко отправляет запросы провайдерам по выяснению IP-адресов. Или сейчас что-то изменилось?

Кстати, по той же теме ... Завтра будет вебинар «Электронные документы в суде: от представления до решения». Эксперты ответят на вопросы в прямом эфире, участие бесплатное.    

Андрей Ардашев 01 сентября 2017 г. 11:52  

Вадим, здравствуйте!

Поясните, пожалуйста, что понимается под термином "частное"

Под термином "частное облако" необходимо понимать, что это облако выделяется только для одной организации, другие организации доступа к этому облаку иметь не будут и не будут влиять на него. В таком случае становится возможным применять политика безопасности компании к доступу на облако. К примеру, может быть использована технологии VPN для объединения ресурсов локальной инфраструктуры с ресурсами облака.

Андрей Ардашев 01 сентября 2017 г. 11:47  

Михаил, благодарю за интересные вопросы!

У нас с вами разное представление о термине "мобильность".

В данном случае имел ввиду мобильность и расширяемость бизнеса-единиц.

Почему нельзя экономить время и освобождать от рутины вне облачной инфраструктуры?

Использование облака - одно из решений и один из трендов, которые дают реальные результаты за короткий срок. 

какой из перечисленных вами рисков, нивелирует пункт "требование SLA ..."?

Основной риск - это потеря данных и доступность данных. SLA регламентирует, как быстро поддержка провайдера примется за работу по устранению инцидента, также SLA основывается не на предположениях, а на существующем плане восстановления. 

а вы оказывается считаете, что публичное облако априори дешевле собственных мощностей...

Верно, не только считаю, но и выгода облаков была доказана расчетом на этапе анализа и внедрения облаков в DIRECTUM. Даже чтобы реализовать простую отказоустойчивую архитектуру потребуется не менее 3 месяцев, существенного количества человеко-часов, специальное помещение, как минимум пара стоек оборудования, не говоря уже о электропитании, охлаждении и регулярной поддержке данного оборудования. Сразу скажу, мы не будем сравнивать ВМ в облаке с единственным сервером. ВМ облаке это продукт отказоустойчивой архитектуры.

Михаил Романов 31 августа 2017 г. 11:06  
1) Как гибридные облака повышают мобильность

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

2) Дополнительная экономия - это прежде всего высвобождение временных ресурсов, оборудования, высвобождение ИТ-службы от рутины, разумеется с целью получения дополнительного дохода

Не понял. Почему нельзя экономить время и освобождать от рутины вне облачной инфраструктуры?

4) Требовать SLA облачного сервиса и следить за его выполнением

Возможно, мы друг друга не поняли, поэтому я переформулирую вопрос: какой из перечисленных вами рисков, нивелирует пункт "требование SLA ..."?

5)У вас есть реальный опыт такой миграции?

Мы опять не поняли друг друга. Я думал, что под

более дешевого публичного облака

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

Андрей Ардашев 31 августа 2017 г. 07:29  

Добрый день, Михаил!

Постараюсь ответить по Вашим вопросам.

1) Как гибридные облака повышают мобильность:

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

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

3) Необходима достаточная пропускная способность каналов до облака
Отличный и очень насущный вопрос, благодарю!

Каждый продукт SaaS имеет определенные технические требования на выч.ресурсы и канал. При работе с облаком можно посчитать какой канал в среднем будет занят пользователями. По нашим расчетам одновременно отправляют запрос лишь 20% от общего числа пользователей. Допустим есть облако SaaS, где требуется на каждого пользователя выделить канал в 512 Кб/с. Всего работает 100 пользователей. В этом случае потребуется выделить канал шириной 100*20%*512Кб/с = 10Мб/с. Также стоит учесть, что сервисов будет не один, а несколько, и один и тот же пользователь не будет одновременно использовать 2 облачных сервиса, соответственно формулу можно усложнить. На самом деле тема очень интересная. Стоит о ней отдельно побеседовать.

4) Требовать SLA облачного сервиса и следить за его выполнением
Форс-мажоры бывают, но довольно редко. Главное во время форс-мажора - не потерять данные. Обычно, в случае форс-мажора ситуация будет исправлена в течение 6 часов. Делать резервную копию данных на своей стороне или на дополнительном защищенном облаке - обязательно. Компенсации по SLA не покроют расходы во время простоя, но каждый форс-мажор укрепляет облако, подключаются дополнительные ресурсы, готовятся обходные пути.

5)У вас есть реальный опыт такой миграции?
Да, само собой. Опыт имеется. Что нужно учитывать:

Обычно путь перемещения такой:

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

2. при переводе продукта в "продуктив" подготовленный продукт/виртуальная машина переносится в частное защищенное облако.

Следует учитывать, чтобы на публично и частном облаке использовалась одна и та же платформа (гипервизор), в этом случае достаточно экспортировать виртуальную машину.

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

Михаил Романов 30 августа 2017 г. 16:49  
Повышается мобильность и оперативность бизнеса

За счет чего?

Обеспечивает дополнительную экономию

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

 

Необходима достаточная пропускная способность каналов до облака

И как вы предлагаете это реализовывать?

Как рассчитать достаточность? Особенно в свете того, что основное преимущество облаков - гибкость в управлении нагрузкой. Вот только в большинстве случаев рост использования серверов пропорционален росту использования канала до них. Т.е. мы сокращаем оборудование в локальном центре, но с перезакладом покупаем канал?

Требовать SLA облачного сервиса и следить за его выполнением

И что это даст в случае реального форс-мажора?

У большинства провайдеров все штрафы за нарушение SLA - это скидки на дальнейшее использование их облака (на очень ограниченный срок) или того пуще - возврат вам денег за аренду на время простоя...

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

У вас есть реальный опыт такой миграции?

А то вот опыт коллег подсказывает, что для того, чтобы иметь возможность развернуть (не перенести, а просто развернуть!) приложение у нескольких облачных провайдеров нужно побеспокоиться об этом заранее еще на этапе разработки и тестирования приложения! И, откровенно говоря, даже применение специализированных средств типа Kubernetes, не даёт гарантию безболезненности данного процесса.

Михаил Романов 21 августа 2017 г. 11:04  

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

Собственно автор на это и уделил вторую часть статьи. Но получилось и правда неотличимо от обычного внедрения.

Андрей Миронов 21 августа 2017 г. 09:55  
Особенности сквозных процессов и документоборота в холдингах

К сожалению не нашел этих самых особенностей. В заключении статьи написаны те же самые цели/задачи, которые решаются при внедрении ECM, не важно холдинг это или обыкновенная организация. 

ИМХО Либо, действительно, таких особенностей нет (в чем я сомневаюсь), либо тема не раскрыта.

Михаил Романов 09 августа 2017 г. 10:47  
А что думаете вы?

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

Это несколько утрированное впечатление от деятельности AIIM в последние годы (хотя я сужу по статьям на EJ - может быть просто для перевода выбирают неудачные).

Андрей Миронов 09 августа 2017 г. 10:13  

Люблю такие исследования - обо всем и ни о чем.

- Гугл, box и прочие наступают на пятки ecm? - само собой эти крупные компании будут развиваться и пробовать себя и свои решения в новых направления. 

- "Расчет наиболее результативных шагов в рамках бизнес-процессов" - по моему этим занимается другой класс систем.

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

А что думаете вы?

Андрей Миронов 09 августа 2017 г. 10:15  
Далее срабатывает интеллектуальный механизм, который, например, в зависимости от содержания письма - сам решает куда далее по маршруту в организации пойдет документ

Это сильно бы ускорила процесс отработки документов, но кто будет отвечать за то, что маршрут будет выбран неправильный или письмо не попадет к нужному человеку?

Вадим Майшев 08 августа 2017 г. 11:16  
Подпись в облаке является КЭП или нет?

Надо разделить нечто под названием "Подпись в облаке" на сущности. Квалифицированная электронная подпись (КЭП) формируется "под документом" в системе электронного документооборота (СЭД) с использованием сертифицированного средства электронной подписи (СЭП), в которое автор помещает свой криптоключ, на который у него есть квалифицированный сертификат (выданный аккредитованным УЦ). 

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

Когда говорят про облачную подпись, то у автора нет ничего, т.к. документ в СЭД, СЭП, и даже криптоключ, хранятся "где-то в облаке" у оператора (а УЦ этого оператора выдал квалисерт), кроме реквизитов для авторизованного доступа к криптоключу. Вопросы для выбора решения: действительно ли СЭП в  облаке сертифицировано для таких условий применения, лежит ли криптоключ именно в этом СЭП (а не рядом с ним), только ли автор владеет "реквизитами доступа" к его криптоключу, с помощью каких средств автор может безопасно дистанционно предъявить эти "реквизиты доступа" оператору, могут ли СЭД других операторов использовать СЭП/криптоключ автора у этого оператора.

По КЭП определить ее локальность или облачность малореально.

Елена Юханова 07 августа 2017 г. 16:24  

Спасибо за ответ.

А требования Приказа ФСБ РФ от 27.12.2011 № 796 "Об утверждении Требований к средствам электронной подписи и Требований к средствам удостоверяющего центра" могут быть применимы к подписи в облаке в частности такие как:

1.    При создании электронной подписи средства электронной подписи должны показывать лицу, подписывающему электронный документ, содержание информации, которую он подписывает (п. 1 ч. 2 ст. 12 Закона и п. 8 Требований).

2.    Средство ЭП должно проводить аутентификацию субъектов доступа (лиц, процессов) к этому средству (п. 25 Требований).

Эти требованяи могут быть соблюдены при удаленном (сетевом) взаимодействии лица, подписывающего электронный документ, со средством ЭП?

Непонятно, над чем работает ФСБ сейчас? какие изменения планируют?