контроль доступа при кэшировании видеоконтента на месте в сети клиента
у нас есть многочасовые обучающие видео-курсы, которые мы хотим провести на месте для клиентов с шифрование или что-то для управления доступом
В настоящее время мы предлагаем услуги через веб-сайт (например, udacity), но некоторые крупные компании хотят, чтобы это было на месте из-за пропускной способности Интернета. Мы не хотим просто передать им жесткий диск с файлами mp4, но нам также не нужно шифрование военного уровня (поскольку, в конце концов, они могут записывать его с помощью видеокамеры)
I ' Я думаю, что мы можем предоставить им медиа-сервер с видео, и чтобы наше локальное веб-приложение работало в их сети и разговаривало с нашим (веб) сервером для отслеживания / получения токенов, а также локально общалось с медиа-сервером для видео.
Мне сказали, что «это предлагают другие провайдеры», но я не знаю «как». Я предполагаю, что они используют Adobe Media Server или что-то в этом роде.
Как я могу «кэшировать локально» видео на сайте с помощью клиента, но при этом иметь некоторый контроль над доступом к видео?
Интересная проблема. Вы хотите передать свою Интеллектуальную собственность третьей стороне таким образом, чтобы они могли отображать ее (через ваш Портал) за своим брандмауэром, но таким образом, чтобы они не могли получить доступ к исходным файлам.
Вы нужно будет предоставить устройство (либо в виде большого OVA - чтобы они могли запускать его на VMware / HyperV / и т. д.), либо в качестве аппаратного обеспечения, которое они могут вставить в стойку и подключиться к своей сети. Учитывая количество задействованных мультимедиа, я подозреваю, что последнее проще. Dell R530 со стеком из 4 ТБ дисков. Готово.
Вам понадобится «безопасная» операционная система. Что-то, что вы можете заблокировать, и установить такие вещи, как Tripwire (чтобы вы могли определить, ткнул ли систему ваш клиент). Вы также можете использовать fail2ban (чтобы вы могли обнаруживать и предотвращать брутфорс ssh) и строгую блокировку IPTables,чтобы из диапазона IP-адресов клиента был доступен только веб-сервис.
Вы можете обнаружить, что политика ИТ-безопасности вашего клиента может препятствовать тому, чтобы ваша система звонила домой (либо для аналитики, либо для «отслеживания / получения токенов» - поэтому я у меня возникнет соблазн создать устройство, в котором будет встроена генерация / авторизация токенов, вместо того, чтобы полагаться на веб-сервис, который может быть недоступен. Если вы можете заставить клиента согласиться с этим, у вас может быть ваш ящик для вызова конечной точки API, которую вы размещаете, чтобы вы могли вытащить настройки, если их нужно обновить. Вы, вероятно, не хотите, чтобы вас видели, как кто-то отправляет на него данные или имеет постоянное соединение ssh, поскольку это вызовет тревогу у группы специалистов по ИТ-безопасности на сайте заказчика.
Вам понадобится носитель. сервер какой-то. Adobe Media Server , вероятно, предлагает больше всего в отношении готовых функций и DRM, но Wowza Media Server также является опцией. Red5 имеет открытый исходный код, но есть профессиональная версия , которая также позволяет кластеризацию высокой доступности.
Наконец, вы, вероятно, захотите предложить некоторый уровень интеграции между существующими системы и вашу, так что это, вероятно, будет через интеграцию LDAP с их Active Directory (типичный метод интеграции предприятия).
Вам также следует попытаться получить аккредитацию вашего устройства у некоторых сторонних консультантов по безопасности, чтобы вы могли его получить подтвердил своим клиентам, что вы не крадете их данные и не подвергаете их новым угрозам.