Frequently asked questions

SEADpods are exclusively available to government entities, encompassing federal, state, and local organisations.

SEADpods are designed to be versatile, allowing interactions with various organisations as intended by the SEAD partner. However, certain restrictions may apply based on project specifications and security considerations as specified by the adopting agency.

Yes, projects can be linked to only the products defined by the administrator, subsequently enabling access to data by a select group of users. Much like the model seen in the shared infrastructure of the DataLab. Noting, administrators however do have access to all data loaded to the environment.

No, there is no limit to how long a SEADpod can exist. The SEADpod will remain in use by the SEAD partner until an explicit termination date is provided.

• The SEAD environment resides on a private virtual network fronted by an Azure firewall.
• Virtual machines (VMs) are blocked from accessing public internet and are segmented by individual workgroup levels.
• All data is encrypted in transit and at rest as we are using Azure hosted storage.
• Role Based Access Control (RBAC) is enforced.
• The SEAD environment is accessed remotely for secure desktop delivery.
• Group policy disables clipboard / device redirection for preventing data theft via Remote Desktop Protocol.
• VMs are automatically patched and we destroy and rebuild all VMs every 14 days on a rolling window.
• Basic user behaviour monitoring is enabled for auditing and reporting purposes. Session recording is not enabled by default.
• ABS utilises the Cloud Security Posture Management (CSPM) tool – InsightCloudSec, which provides information about potential misconfigurations, configuration drift and any security issues following deployment of resources.
• VMs are protected with Microsoft Defender for Endpoint Plan 2 (previously Microsoft Defender Advanced Threat Protection) which provides:
  • Threat detection.
  • Antivirus / malware scanning.
  • Preventative protection / post breach detection.
  • Automated remediation and response.
  • Vulnerability management.
  • Other next-gen protections.

SEAD Users are not able to load code or packages themselves, this responsibility sits with partner Data Administrators and the ABS. To ensure system security and integrity, SEAD partner administrators should refer to their 'SEAD Administrators Instruction Guide' provided by the ABS for information on trusted sources. In addition, software is not to be provided, or attempted to be loaded to a SEADpod by partner administrators. Any request for new software must be submitted to the ABS, accompanied by a business justification.

Project and Output folders within each workspace are backed up each night and retained for 14 days. These backup snapshots are accessible to SEAD administrators. Product blob containers and Project datalake containers are not currently backed up.

Closed projects will also be archived 30 days after their closure date. Data from P: (Project) and O: (Output) file shares will be moved from the Project storage account to a dedicated archive storage account. The ability to restore a project will no longer be available after the 30 days grace period and requests to restore an archived project will incur a cost.

SEAD facilitates collaborative engagement on shared projects. SEAD partner administrators have the capability to create user accounts for internal or external (third party) users and strategically assign them to specific projects. It is up to the SEAD partner to determine and manage data access policies.

Data ingress and egress is managed by Data Administrators through Azure Storage Explorer by uploading and downloading files from Azure Files Storage Accounts. Azure Storage Accounts are configured with a firewall to restrict access to an administrator's nominated network.

Azure Storage Explorer is the preferred storage client for SEAD. There are alternative options available, but this is up to the SEAD partner to manage and should be discussed in consultation with the ABS before onboarding. The choice depends on specific project requirements.

Users cannot upload or download any data to/from SEAD, this is only done by a Data Administrator for security purposes.

Virtual Machines (VMs) are the virtual workspaces analysts use to undertake their work in SEAD. An analyst will have one VM for each project they are a member of and can only work in one of these (the ‘Active’ VM) at any given time. This is a security measure to prevent analysts from accessing data for multiple projects simultaneously. The VMs are also called ‘Desktops’ in Azure Virtual Desktop. Only SEAD Project Administrators can assign VMs to users.

The appropriate VM size will depend on the size, complexity, and needs of the analysts working on a given project. Larger and more complex files and analytical tasks may require larger machines. We advise users to use small, medium or large machines in the first instances. There are cost implications on VM use. Refer to Available features for more information about VM sizes and performance. Users have the ability to manage their VMs power state in SEAD.

Yes, VM GPU units are available at an additional cost. Refer to Available features for information on Virtual Machine sizes.

VM Project and Output drives are backed up every night and kept for 14 days. Files outside of these drives are not recoverable.

Yes, it takes about 5 minutes to process the connection. You may also need to log out of your VM to allow the system to refresh your session with the new data.

VMs are destroyed approximately every 14 days for security purposes. If the rebuild timing will interfere with the your project timelines, you can choose to destroy and rebuild earlier than 14 days at a time that suits you.

Yes, users are reminded about a rebuild three days ahead of their rebuild and again 24 hours prior.

No, there is no predetermined limit to the amount of data that can be stored in a SEADpod. By design, SEAD is a scalable environment. However, by default each project workspace is provisioned 1TB, which can be increased by administrators to 10TB of storage. Additional storage can be provided upon request to the ABS, to a maximum of 100TB per project imposed by the Azure platform. Cost management should be considered when thinking about storage applications.

Yes, system usage charges will vary depending on the forecasted usage profile, including, but not limited to, storage, number of accounts, license use and VM use.

The cost of storage in the Product and Project File shares is generally higher than the Product and Project (datalake) blob containers. However, backups are currently only configured for Azure file shares (Project and Output drives), which are backed up nightly and retained for 14 days. The total cost of storage is dependent on the amount of data being held, as well as the total number of read/write operations to the storage container.

The Products storage account provides 100TB of storage, separate from your projects allocated drive capacity, typically 1TB by default. Access to Individual folders (products) inside the Product drive are controlled separately by Project Administrators who must link the product to a specific project before it becomes accessible to users.

For storing data products, it is preferable for Data Administrators to use the Products folder as the products can be linked to as few or as many projects as required. Users have read-only access to the Products folder. When working on datasets/code it’s preferable to use the Projects drive, due to the persistent storage and enabled backups which are not impacted by the 14 day rebuild. Users should save files to the Outputs drive when you need items extracted from the project by a Data administrator.  Do not save files to the C drive, as these will be deleted during a rebuild and are not recoverable.

Like DataLab, SEAD is already equipped with various 'standard' software for SEAD partners to utilise at no additional cost, including R, Python, STATA, VS Code, Winmerge, QGIS, and 7ZIP (for the full list of software, see Available features). Standard software is cost recovered (where relevant) through the SEAD partners standard system usage charges. However, new software or software that requires paid licensing will incur additional charges. For example, Databricks and SAS are available but will incur a cost. Other non-standard software tooling can be requested by SEAD partners for implementation in the system, and will be considered on a case-by-case basis. 

Yes, SEAD administrators can assign and reassign SAS licenses as required because SAS licenses are managed through a concurrent license pool arrangement. If the SEAD partner pays for 10 concurrent licenses, a maximum of 10 users can use a SAS-enabled VM at the same time. If an 11th user tries to access SAS concurrently, access will be restricted until a licenses become available. Since the licenses are pooled, any number of users in your SEADpod can be assigned a SAS enabled machine but they cannot be accessed concurrently. SEAD administrators can monitor this by exporting reports from the Virtual Machines page on the SEAD portal.

Once confirmation to proceed with the SEAD service is provided, we can facilitate a free 30-day trial period. See Applying for the SEAD service. for further information about the application process.