Как стать автором
Обновить
19
0.9
Михаил Захаров @MikhailZakharov

product manager in b2b

Отправить сообщение
Managed Service Accounts могут усложнить задачу. Пароль автоматически регулярно меняется без участия админа. Только атака на конкретное приложение. От инсайда, как в этом примере спасет, если только инсайдер не имеет доступ к сертификатам.
Собственный алгоритм — зло, выкидываем. Остаются стандартные алгоритмы, ключи от которых хранятся где?

В случае стандартного развертывания на EC2 приложение — и есть инстанс, вы ничего не можете «сузить».


Это, действительно, важный момент. В моей практике есть только ПО, которое работает на Windows Server. Там в качестве хранилища можно использовать как встроенный контейнер сертификатов, так и стороннее ПО типа Крипто API. Доступ к ключу будет иметь определенный аккаунт под которым работает ПО.
Обычно под конкретное приложение дается отдельный аккаунт. Т.е. в этом случае надо получать доступ именно к нему. То есть слабым звеном остаюся администратор, который имеет доступ к хранилищу сертификатов и учетная запись, под которой крутится сервис-приложение.

В случае с EC2 приложением, наверное да, только использование встроенных в AWS сервисов.
С помощью собственного алгоритма, или стороннего crypto service provider. Про пояснение о S3 спасибо (все хочу посмотреть детали). Такие требования появляются из-за случаев с Capital One. Тоесть получение привелегий учетной записи, под которой работает инстанс приложения, не должен давать доступ к данным. Внутреннее шифрование сужает доступ до приложения (как владельца ключа). Ключ, конечно, тоже можно стащить, но это другая история.
Инстанс имеет доступ к чтению, и читает он шифрованные данные. Расшифровка идет в памяти. Аналогия. Развернута виртуальная машина, на которой ничего нет, кроме «Блокнота». Инстансу — этой виртуалке дали доступ на чтение к хранилищу. Блокнот умеет шифровать. Хакер получает доступ к инстансу и может прочитать сохраненные в хранилище данные блокнота, но там они шифрованы.
Я не эксперт в AWS, могу здесь ошибиться. Когда приложение пишет данные в хранилище (неважно где оно расположено), этот поток уже может быть зашифрован. То есть получая доступ к хранилищу, сами данные нужно будет дешифровать.
В дополнение к выводам. В последние несколько лет чаще стали требовать от продуктов поддержки внутреннего шифрования. Если хакер получает достаточные привелегии для скачивания данных, то еще их нужно будет расшифровать.
Спасибо за ответ. По последнему пункту, поправьте меня, если я неправильно понял. Ваша платформа предоставляет API и свой язык для разработки модулей. Плюс у вас есть набор готовых модулей, условно CRM. Заказчик покупает продукт Платформа + CRM, но ему нужны доработки. Вы делаете CRM ver. 2 и размещаете в своем репозитории.

Заказчик при использовании CRM ver.2 загружает ее себе и использует локально? В чем отличие от доработок других продуктов. Компания «A» тоже может выпустить доработку для своего софта «ERP A» в виде патча и передать заказчику.

Мне казалось, что идея в том, что CRM ver.2 находится в облаке. Фактически заказчик использует Платформу в облаке и модуль / модули в облаке. Вам так будет удобнее дорабатывать и сопровождать. В этом случае ему нужны гарантии по доступу (SLA).

Еще вопрос по модульности и доработкам. Если взять к примеру демо ERP. В качестве требования заказчик хочет добавлять распознанные накладные со сканера. Т.е. некий сервис распознавания возвращает извлеченные данные + картинку. Платформа позволяет делать такие доработки?
Интересно. Это вроде конфигураций 1С, верно? При данном подходе каждая конфигурация клиента хранится в репозитории.
Как происходит обновление конфигураций при обновлении платформы? Или совместимость никогда не ломается? Вы хостите «конфигурации» у себя. Есть ли гарантии для заказчиков?
Можно решить существующую проблему. Можно создать проблему (= организовать рынок) и ее решить.
После некоторого периода тестового использования вы собираете мнения первых клиентов о продукте, определяете направления для развития продукта и далее выстраиваете осмысленные, серийные продажи.

Здесь надо быть осторожным. Первые отзывы могут воодушевить, легко свернуть с изначальной модели. Первый заказчик важен, но это не все заказчики.

Хорошо, что затронута тема стоимости привлечения клиента. Есть одна постоянная зависимость (рад буду увидеть контрпример), чем крупнее ваш потенциальный заказчик, тем выше стоимость. Длительность сделки в enterprise может легко превысить год.
Еще тень от смартфона иногда мешает. Office Lens вроде неплохо справляется с мобильным фото документов.
Только они ограничены почтой, диском, FTP и максимум SharePoint. Когда надо сканировать в ECM системы или Capturing, уже не все так просто. Для типичного офисного работника, сканирование в почту подходит. Для делопроизводителя или оператора сканирования нет.
Светофоры у них обычные: зеленый езжай, красный стой. Только все горизонтально размещены над дорогой.
А вот пешеходные светофоры имеют «прогрес бар». Две полоски уменьшаются со временем. По началу думаешь, что тебе 11 секунд остается, но это две полоски

Именно, красный — свободно


Есть и интересные решения. Лампочка над местом в поезде. Красный цвет — место свободно, зеленый цвет — место занято.
Желтый — займут на следующей станции.
Можно попробовать использовать SDK для веб сканирования. Чтобы не рекламировать продукты, просто поищите по «web scanning SDK». По архитектуре некоторые из них используют плагины для браузера (этот вариант не подходит), а другие ставят прокси сервис, который общается со сканером. Можно подключить старый ноутбук на windows с таким сервисом к сканеру. Несмотря на то, что все это SDK, многие идут с простым демо приложением, которого достаточно для сканирования. Их можно расширить.

Похожий вариант, но бесплатный — TWAIN Direct Bridge. Схема та же. Bridge ставится как прокси на windows машину. Обещают выпустить к 3 квартале 2019 https://www.twain.org/forums/topic/twain-bridge/

Есть сканеры, которые позволяют подключаться с мобильного устройства по wi fi. Такие сканеры создают точку доступа, а на телефоне должно стоять приложение от производителя.


Также есть сканеры, к которым с десктопа можно подключаться по wi fi. Я знаю только одно устройство, которое работает так


Приложение — isis driver — wi fi — сканер.
И так.
Приложение — rest API — сканер.


То есть для линукса подойдёт только второй вариант, но нужно писать свое приложение.


Возможно есть сканеры, которые могут показывать веб интерфейс сканирования.

Статья про подходы для сканирования по сети. Приведу пример. Делаете вы новое приложение для обработки заявок (кредит, регистрация), нужен ввод документов. Надо как-то интегрироваться. Можно сделать только импорт с диска. Или уметь подключаться к сканеру напрямую. Вопрос в том, надо ли подключаться к сканеру, или нужно научить сканер отправлять документы в вашу систему.
Вы правы, WSD нужно было упомянуть. Хотя бы потому, что эта технология была поддержана некоторыми вендорами.
Дрожащие руки исправить сложнее. Есть SDK для мобильного сканирования, которые могут брать видеопоток и отбирать лучшие кадры. Все больше телефонов умеют снимать в высоком разрешении, и в 60 кадров/сек.

Еще есть один интересный факт. Apple перестали поддерживать список встроенных драйверов в macOS. Сейчас на сайте висит сообщение, что раз технологии меняются (упоминают, правда, AirPrint) то сопровождать встраиваемые драйвера смысла нет.
Именно на этом и хотел сделать акцент. Сканирование с устройства прямо в папку (почту, ECM) удобнее чем открытие приложения и сканирование в него. Это поддерживают уже и относительно недорогие устройства. Новым технологиям для связи со сканером уже места нет.

Информация

В рейтинге
1 635-й
Откуда
Санкт-Петербург, Санкт-Петербург и область, Россия
Зарегистрирован
Активность