Para muchos clientes de Zencoder, garantizar la seguridad de sus contenidos durante el proceso de transcodificación es una prioridad absoluta. Ahora que Zencoder admite entradas cifradas, los clientes pueden asegurarse de que sus datos nunca se almacenan en formato plano mientras fluyen por Zencoder. En resumen, Zencoder puede aceptar entradas cifradas, descifrarlas para la transcodificación y, a continuación, volver a cifrar los vídeos de salida antes de escribirlos en una ubicación de almacenamiento. La importancia de este flujo de trabajo radica en que tanto las entradas como las salidas están protegidas. Si un usuario no autorizado pudiera acceder a estos archivos cifrados, no podría verlos sin el par de clave e IV utilizado para cifrarlos. Veamos cómo sería este proceso. Antes de empezar, necesitaremos una entrada encriptada. Para este ejemplo, cifraremos un archivo localmente usando OpenSSL, luego lo subiremos a S3 antes de crear el trabajo de transcodificación.
$ openssl aes-256-cbc -k zencoderisawesome -in trailer_test.mp4 -out trailer_test.mp4.enc -p
En -k
es el secreto que queremos utilizar, que en este caso es "zencoderisawesome". La dirección -p
indica a OpenSSL que imprima la clave cuando termine, que necesitaremos para descifrar más tarde. Para nosotros, la salida se veía así:
salt=9E7E90A964768A2F
key=DAFF64EAE3B3AB9C7905871E407293D4987E16DE76578372E161B1261F39CD66
iv =375FDBBB213C062D544FCB5A6ACBA44E
Ahora el archivo está encriptado, por lo que no deberías poder reproducirlo como antes. Ahora tenemos que subir el archivo a S3 o a un servidor FTP en algún lugar para que Zencoder pueda acceder a él. Usaremos la interfaz de carga de S3.Es hora de construir la solicitud. Utilizaremos la función Biblioteca Node.js para enviar la solicitud en estos ejemplos, pero las mismas solicitudes también podrían enviarse utilizando otra herramienta como la aplicación Solicitar constructor. Tendremos que especificar la clave de cifrado y el IV que utilizamos anteriormente para la entrada.
var zencoder = require('zencoder')();
zencoder.Job.create({
input: "s3://zencoder-demo/trailer_test.mp4.enc",
decryption_method: "aes-256",
decryption_key: "DAFF64EAE3B3AB9C7905871E407293D4987E16DE76578372E161B1261F39CD66",
decryption_password: "zencoderisawesome"
}, function(err, data) {
if (err) {
console.log("Job wasn't created");
return console.log(err);
}
console.log("Woo!");
console.log(data);
});
Esto sería suficiente para crear una salida h.264 estándar, pero no estaría encriptada de ninguna manera. A veces esto es útil, porque puedes querer tomar un archivo mezzanine encriptado (un archivo de muy alta calidad usado para crear otras salidas de menor calidad) y usarlo para marcas de agua o salidas de menor calidad para distribución. Supongamos que queremos tomar un archivo intermedio y subirlo a tres servicios diferentes. Queremos que una de las salidas sea una versión sin cifrar, de baja calidad y con una marca de agua, y que las otras dos estén cifradas con dos claves diferentes, una con una marca de agua identificativa y la otra sin ella. Antes de que podamos crear esta solicitud, sin embargo, tendremos que generar las dos claves que vamos a utilizar. Usaremos OpenSSL de nuevo para crear estas nuevas claves:
$ openssl enc -aes-256-cbc -k supersecret -P
salt=12B83BBF81DFA5B7
key=48A9E3FA8A629AEBA5B4F1FAC962920F0D7084E306E0D01A0ED01C920BBCBD08
iv =2B3CABAB503198DB32394245F54E2A34
$ openssl enc -aes-256-cbc -k anothersecret -P salt=DE2DE044EA5FEB2A key=3AAE9D6E5212224BB9F76E328D2BD826F17B4FC292845B6E3B72634D2C28052D iv =169C3DE53C56E74130CDA57BA85F8255
Ahora podemos utilizar estas claves cuando encriptamos las salidas durante el proceso de transcodificación.
zencoder.Job.create({
input: "s3://zencoder-demo/trailer_test.mp4.enc",
decryption_method: "aes-256",
decryption_key: "DAFF64EAE3B3AB9C7905871E407293D4987E16DE76578372E161B1261F39CD66",
decryption_password: "zencoderisawesome",
outputs: [
{
url: 's3://some-bucket/decrypted.mp4',
quality: 3,
width: 320,
watermarks: [{
url: 's3://zencoder-live/test-job-watermark.png'
}]
},
{
url: 's3://some-other-bucket/encrypted-watermarked.mp4',
width: 720,
watermarks: [{
url: 's3://zencoder-live/test-job-watermark.png'
}],
encryption_method: "aes-256",
encryption_key: '48A9E3FA8A629AEBA5B4F1FAC962920F0D7084E306E0D01A0ED01C920BBCBD08',
encryption_iv: '2B3CABAB503198DB32394245F54E2A34'
},
{
url: 's3://some-bucket/encrypted-out.mp4',
width: 720,
encryption_method: "aes-256",
encryption_key: '3AAE9D6E5212224BB9F76E328D2BD826F17B4FC292845B6E3B72634D2C28052D',
encryption_iv: '169C3DE53C56E74130CDA57BA85F8255'
}
]
}, function(err, data) {
if (err) {
console.log("Job wasn't created…");
return console.log(err);
}
console.log("Woo!");
console.log(data);
});
Omitir la encriptación de una salida y encriptar otras dos por separado puede parecer una locura, pero considera el caso de uso. La salida de baja calidad podría utilizarse como muestra (incluso podrías crear un clip más corto para este fin). Una de las versiones de alta calidad tiene una marca de agua que identifica a la persona a la que se ha subido el vídeo, por lo que podrías proporcionarle la clave para descifrarlo y verlo, y si alguna vez se encuentra el vídeo fuera de su control sabrías de quién era la copia. La tercera copia, sin marca de agua, se volvería a subir a un cubo que controláramos, de modo que pudiéramos utilizarla para distribuirla más tarde. Una vez que tengas uno de estos archivos encriptados localmente, puedes desencriptarlo usando un proceso similar al que usamos para encriptarlo originalmente. Para desencriptar el archivo con marca de agua: $ openssl enc -aes-256-cbc -d -K 48A9E3FA8A629AEBA5B4F1FAC962920F0D7084E306E0D01A0ED01C920BBCBD08 -iv 2B3CABAB503198DB32394245F54E2A34 -in encrypted-watermarked.mp4 -out decrypted-watermarked.mp4
Para desencriptar el archivo sin la marca de agua: $ openssl enc -aes-256-cbc -d -K 3AAE9D6E5212224BB9F76E328D2BD826F17B4FC292845B6E3B72634D2C28052D -iv 169C3DE53C56E74130CDA57BA85F8255 -in encrypted-out.mp4 -out decrypted-out.mp4
¡Ya está! Ahora tienes una tubería de codificación encriptada de extremo a extremo. El archivo encriptado usado en estos ejemplos está disponible en esa ubicación y fue realmente encriptado usando estas credenciales, así que siéntete libre de usarlo como archivo de prueba. Sólo una notaNo hay que confundir esto con la gestión de derechos digitales (DRM). Una solución DRM adecuada gestiona aspectos como los derechos de acceso a los contenidos, que pueden ser mucho más granulares, hasta determinados dispositivos y usuarios. Los archivos encriptados sólo pueden verse con la clave de encriptación y la contraseña asociada, pero ése es el único criterio.