Назад | Перейти на главную страницу

контроль доступа при кешировании видеоконтента на сайте в сети клиента

у нас есть многочасовые видеокурсы, которые мы хотим предоставить клиентам на месте с помощью шифрования или чего-то еще для контроля доступа

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

Я думаю, мы можем предоставить им медиа-сервер с видео, и наше локальное веб-приложение будет работать в их сети и разговаривать с нашим (веб) сервером для отслеживания / получения токенов и локально общаться с медиа-сервером для видео.

Мне сказали, что «это предлагают другие провайдеры», но я не знаю «как». Я предполагаю, что они используют Adobe Media Server или что-то в этом роде.

Как я могу «кэшировать локально» видео на сайте с помощью клиента, но при этом иметь некоторый контроль над доступом к видео?

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

  1. Вам нужно будет предоставить устройство (либо в виде огромного OVA - чтобы они могли запускать его на VMware / HyperV / и т. Д.), Либо в качестве аппаратного обеспечения, которое они могут вставить в стойку и подключиться к своей сети. Учитывая количество задействованных мультимедиа, я подозреваю, что последнее проще. Dell R530 со стеком из 4 ТБ дисков. Готово.

  2. Вам понадобится «безопасная» операционная система. Что-то, что вы можете заблокировать, и установить такие вещи, как Tripwire (чтобы вы могли определить, ткнул ли ваш клиент в систему). Вы также можете использовать fail2ban (чтобы вы могли обнаруживать и предотвращать брутфорс ssh) и строгую блокировку IPTables, чтобы только веб-сервис был доступен из диапазона IP-адресов клиента.

  3. Вы можете обнаружить, что политика ИТ-безопасности вашего клиента может препятствовать тому, чтобы ваша система звонила домой (либо для аналитики, либо для «отслеживания / получения токенов», поэтому у меня возникнет соблазн создать устройство, в котором будет встроена генерация / авторизация токенов. , вместо того, чтобы полагаться на веб-сервис, который может быть недоступен. Если вы можете заставить клиента согласиться с ним, вы можете сделать так, чтобы ваш ящик звонил домой к конечной точке API, которую вы размещаете, чтобы вы могли получить настройки если они нуждаются в обновлении. Вы, вероятно, не хотите, чтобы вас видели, как кто-то отправляет туда данные или имеет постоянное соединение ssh, так как это вызовет тревогу у группы специалистов по ИТ-безопасности на сайте заказчика.

  4. Вам понадобится какой-нибудь медиа-сервер. Adobe Media Server вероятно, предлагает больше всего в отношении готовых функций и DRM, но Wowza Медиа-сервер также возможен. Красный5 с открытым исходным кодом, но есть профессиональная версия это также позволяет кластеризацию с высокой доступностью.

  5. Наконец, вы, вероятно, захотите предложить некоторый уровень интеграции между их существующими системами и вашей, так что это, вероятно, будет через интеграцию LDAP с их Active Directory (типичный метод интеграции предприятия).

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