Рекомендуемая практика доступа к хранилищу BLOB-объектов

Поскольку мы создаем приложение Saas и существует требование, согласно которому мы хотим хранить некоторые счета в виде больших двоичных объектов Azure внутри контейнера, чтобы создать большой двоичный объект внутри контейнера через REST API (здесь мы используем nodejs), я нашел два варианты завершения процесса

  1. Создание назначения роли и назначение его в качестве разрешений роли
  2. Путем создания токенов SAS с некоторыми спецификациями, такими как ключи делегирования пользователей.

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

Является ли назначение ролей через принцип обслуживания уязвимым? Если да, то как насчет SAS и его периодического запроса токена и его проверки? Любая справочная документация будет полезна.

🤔 А знаете ли вы, что...
Node.js позволяет использовать один и тот же язык (JavaScript) на клиентской и серверной стороне.


63
1

Ответ:

Решено

Является ли назначение ролей через принцип обслуживания уязвимым? Если да, то как насчет SAS и его периодического запроса токена и его проверки? Любая справочная документация будет полезна.

Для подхода к автоматизации создания больших двоичных объектов внутри контейнера я бы посоветовал вам выбрать RBAC место, где требуется непрерывный долгосрочный доступ, используя субъект-службу с соответствующими ролями RBAC, например Storage Blob Data Contributor вы можете получить к нему доступ.

Где SAS tokens предоставляют ограниченный по времени доступ к определенным ресурсам (например, контейнеру или BLOB-объекту) и определенным разрешениям (например, записи или списку). Таким образом, токен SAS будет полезен в сценариях, когда потребность в доступе является временной или периодической.

Является ли назначение ролей через принцип обслуживания уязвимым? ,

  • Если их учетные данные раскрыты или плохо управляются, субъекты-службы могут быть рискованными.
  • Чтобы решить эту проблему, важно регулярно менять учетные данные и обеспечивать строгий контроль доступа.

Вот код node.js для аутентификации с использованием субъекта-службы и создания большого двоичного объекта в хранилище BLOB-объектов Azure.

Сначала создайте субъекта службы и назначьте ему роль Storage Blob Data contributor, используя этот MS-Document.

Код:


const { DefaultAzureCredential } = require('@azure/identity');
const { BlobServiceClient } = require('@azure/storage-blob');

// Replace with your values
const accountName = "venkat32xxx3";
const containerName = "sample";
const blobName = "test.txt";
const content = "Hello, World!";

// Authenticate using DefaultAzureCredential
const credential = new DefaultAzureCredential();
const blobServiceClient = new BlobServiceClient(`https://${accountName}.blob.core.windows.net`, credential);

async function createBlob() {
  try {
    const containerClient = blobServiceClient.getContainerClient(containerName);
    await containerClient.createIfNotExists();
    const blockBlobClient = containerClient.getBlockBlobClient(blobName);
    await blockBlobClient.upload(content, Buffer.byteLength(content));
    console.info(`Blob "${blobName}" is uploaded successfully.`);
  } catch (error) {
    console.error('Error uploading blob:', error);
  }
}

Для настройки сохраните учетные данные субъекта-службы как переменные среды.

AZURE_CLIENT_ID=<your-client-id>
AZURE_CLIENT_SECRET=<your-client-secret>
AZURE_TENANT_ID=<your-tenant-id>

Выход:

Blob "test.txt" is uploaded successfully.