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