Safety of projects in Collaborate

Hi. We don't have an official FAQ for security questions yet. Until then:

Account Access. This is not data technically stored with your repository but should be mentioned. I can't talk too specifically about what we're doing in Unity ID other than we're continuing to make it more secure. On the front end, we've recently added 2FA to add an additional layer of security to accounts (works with your phone).

Project Access. Access to your the project can be added/revoked at any time, to those with a UnityID. Of course, because clients download assets to their local machine, they can retain versions of project separately. We'll likely add features to give more granular control over a project e.g. read only, write to only certain parts of a project, etc.

I don't understand the concern that "One potential vulnerability that bothers me is the ability to just add anyone to a project as a team member." What is driving the current experience is that we expect customers want few road blocks to working with others; so, it's easy. If it's too easy, there are enough roles / privileges provided today to limit the number of users who can grant project access e.g. only have one "Owner" in your org.

Data. Encrypted in transit. In the future, possibly at rest too, as an option. The issue is it WILL result in a performance hit, but very unlikely to make things more secure e.g. if it was a h4x0r, it would be easier for me to steal a password than physically break into a world class datacenter (so enable that 2FA!)

Additionally, we don't look at project data unless a customer gives us very explicit permission. This privilege is extremely limited; used to address support issues. In addition to people policies to limit access, there's also application policies.

Security Testing. We audit on a regular basis. Not providing details here on purpose

Hope this helps. Let me know if there’s something missing; will help us draft the actual FAQ

 

To your first point, I've talked with Unity users that don't like any cloud solution because of this inherent risk. To some, a more secure solution is to keep an onsite disk in a closet. Both have risks and costs.

Encryption in transit does not automatically mean its encrypted at rest. As mentioned, we currently do not encrypt at rest. It has a necessary impact on performance but doesn't necessarily make things more secure. This might seem odd but it's not out of the ordinary for cloud based services (e.g. GitHub). Encryption at rest helps mitigate physical compromise but other vectors are way more likely.

 

Right now, you could probably figure out that we store stuff on AWS. So,

https://d0.awsstatic.com/whitepapers/Security/AWS_Security_Whitepaper.pdf

Section that is relevant to this conversation

Physical and Environmental Security

AWS’s data centers are state of the art, utilizing innovative architectural and engineering approaches. Amazon has many years of experience in designing, constructing, and operating large-scale data centers. This experience has been applied to the AWS platform and infrastructure. AWS data centers are housed in nondescript facilities. Physical access is strictly controlled both at the perimeter and at building ingress points by professional security staff utilizing video surveillance, intrusion detection systems, and other electronic means. Authorized staff must pass two-factor authentication a minimum of two times to access data center floors. All visitors and contractors are required to present identification and are signed in and continually escorted by authorized staff.

AWS only provides data center access and information to employees and contractors who have a legitimate business need for such privileges. When an employee no longer has a business need for these privileges, his or her access is immediately revoked, even if they continue to be an employee of Amazon or Amazon Web Services. All physical access to data centers by AWS employees is logged and audited routinely.​