Für viele Zencoder-Kunden hat die Sicherheit ihrer Inhalte während des Transcodierungsprozesses oberste Priorität. Da Zencoder nun verschlüsselte Eingaben unterstützt, können Kunden sicherstellen, dass ihre Daten niemals im Klartext gespeichert werden, während sie Zencoder durchlaufen. Kurz gesagt, Zencoder kann verschlüsselte Eingaben akzeptieren, sie für die Transkodierung entschlüsseln und dann die Ausgabevideos erneut verschlüsseln, bevor sie an einen Speicherort geschrieben werden. Die Bedeutung dieses Arbeitsablaufs liegt darin, dass sowohl die Eingaben als auch die Ausgaben geschützt sind. Wenn ein unbefugter Benutzer auf diese verschlüsselten Dateien zugreifen könnte, könnte er sie ohne das zur Verschlüsselung verwendete Schlüssel-IV-Paar nicht anzeigen. Gehen wir einmal durch, wie dieser Prozess aussehen würde. Bevor wir beginnen, benötigen wir eine verschlüsselte Eingabe. In diesem Beispiel verschlüsseln wir eine Datei lokal mit OpenSSL und laden sie dann auf S3 hoch, bevor wir den Transcodierungsauftrag erstellen.
$ openssl aes-256-cbc -k zencoderisawesome -in trailer_test.mp4 -out trailer_test.mp4.enc -p
Die -k
Flag ist das Geheimnis, das wir verwenden wollen, in diesem Fall "zencoderisawesome". Die -p
Flagge weist OpenSSL an, den Schlüssel auszugeben, wenn es fertig ist, den wir später für die Entschlüsselung benötigen. Für uns sah die Ausgabe wie folgt aus:
salt=9E7E90A964768A2F
key=DAFF64EAE3B3AB9C7905871E407293D4987E16DE76578372E161B1261F39CD66
iv =375FDBBB213C062D544FCB5A6ACBA44E
Jetzt ist die Datei verschlüsselt, du solltest sie also nicht mehr abspielen können, wie du es vorher getan hättest. Jetzt müssen wir die Datei irgendwo auf S3 oder einen FTP-Server hochladen, damit Zencoder darauf zugreifen kann. Wir werden einfach die S3-Upload-Schnittstelle verwenden.Zeit, die Anfrage zu erstellen. Wir verwenden die Node.js-Bibliothek um die Anfrage in diesen Beispielen zu senden, aber die gleichen Anfragen könnten auch mit einem anderen Tool wie dem Anfrage Builder. Wir müssen den Verschlüsselungsschlüssel und den IV, den wir oben für die Eingabe verwendet haben, angeben.
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);
});
Dies würde ausreichen, um eine standardmäßige h.264-Ausgabe zu erstellen, die jedoch in keiner Weise verschlüsselt wäre. Manchmal ist dies nützlich, weil man eine verschlüsselte Mezzanine-Datei (eine sehr hochwertige Datei, die zur Erstellung anderer, weniger hochwertiger Ausgaben verwendet wird) für Ausgaben mit Wasserzeichen oder geringerer Qualität zur Verteilung verwenden möchte. Nehmen wir an, wir wollen eine Mezzanine-Datei nehmen und sie auf drei verschiedene Dienste hochladen. Eine Ausgabe soll eine unverschlüsselte Version niedriger Qualität mit einem Wasserzeichen sein, die beiden anderen sollen mit zwei verschiedenen Schlüsseln verschlüsselt werden, einer mit und einer ohne Wasserzeichen. Bevor wir diese Anfrage erstellen können, müssen wir jedoch die beiden Schlüssel generieren, die wir verwenden werden. Wir werden wieder OpenSSL verwenden, um diese neuen Schlüssel zu erzeugen:
$ 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
Jetzt können wir diese Schlüssel verwenden, wenn wir die Ausgaben während des Transcodierungsprozesses verschlüsseln.
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);
});
Die Verschlüsselung einer Ausgabe wegzulassen und zwei andere separat zu verschlüsseln, mag verrückt erscheinen, aber bedenken Sie den Anwendungsfall. Die Ausgabe mit niedriger Qualität könnte als Beispiel verwendet werden (Sie könnten sogar einen kürzeren Clip für diesen Zweck erstellen). Eine der hochwertigen Versionen ist mit einem Wasserzeichen versehen, das die Person identifiziert, für die das Video hochgeladen wurde, so dass Sie ihr den Schlüssel zum Entschlüsseln und Anschauen geben können. Die dritte, nicht mit Wasserzeichen versehene Kopie würde wieder in einen von uns kontrollierten Bucket hochgeladen, damit wir sie später für die Verbreitung verwenden können. Sobald Sie eine dieser verschlüsselten Dateien lokal haben, können Sie sie mit einem ähnlichen Verfahren entschlüsseln, wie wir es ursprünglich zur Verschlüsselung verwendet haben. So entschlüsseln Sie die mit einem Wasserzeichen versehene Datei: $ openssl enc -aes-256-cbc -d -K 48A9E3FA8A629AEBA5B4F1FAC962920F0D7084E306E0D01A0ED01C920BBCBD08 -iv 2B3CABAB503198DB32394245F54E2A34 -in encrypted-watermarked.mp4 -out decrypted-watermarked.mp4
So entschlüsseln Sie die Datei ohne Wasserzeichen: $ openssl enc -aes-256-cbc -d -K 3AAE9D6E5212224BB9F76E328D2BD826F17B4FC292845B6E3B72634D2C28052D -iv 169C3DE53C56E74130CDA57BA85F8255 -in encrypted-out.mp4 -out decrypted-out.mp4
Das war's! Sie haben jetzt eine durchgängig verschlüsselte Verschlüsselungspipeline. Die verschlüsselte Datei, die in diesen Beispielen verwendet wird, ist an diesem Ort verfügbar und wurde tatsächlich mit diesen Anmeldeinformationen verschlüsselt, Sie können sie also gerne als Testdatei verwenden. Nur eine AnmerkungDies ist nicht zu verwechseln mit der digitalen Rechteverwaltung (DRM). Eine richtige DRM-Lösung regelt Dinge wie die Zugriffsrechte auf Inhalte, die sehr viel detaillierter sein können, bis hin zu bestimmten Geräten und Benutzern. Verschlüsselte Dateien können nur mit dem Verschlüsselungsschlüssel und dem zugehörigen Kennwort angesehen werden, aber das ist das einzige Kriterium.