In February 1990, Adobe released Adobe Photoshop 1.0

by Marius Marinescu / 24 February

Photoshop is arguably the most widely used, most popular and most powerful photo-editing software in the world and although many of today’s Photoshop users probably can’t imagine a world without the application, it’s important to remember that Photoshop has only been around for 34 years.
Today, Photoshop is an extremely powerful piece of software but it hasn’t always been this way. If you rewind 34 years, Photoshop didn’t exist at all and even when the application was initially created, it was a far-cry from the hugely powerful application that we know and love today.
From the humble beginnings in 1987 as a small subroutine for a program on Apple II Plus that allowed the translation of monochromatic images to greyscale to the release of Adobe Photoshop CC in June 2013, Photoshop is now used by amateurs and professionals alike for everything from simple image retouching to website design. The software has truly changed the world of photography and design but we mustn’t forget, it took 34 years of constant improvements to get to this stage.
Adobe Photoshop CC released in 2013 marked a new era for the application as it moved away from the Creative Suite series and began a new journey under the Creative Cloud (CC) name. With previous versions of Photoshop (including the Creative Suite series), users would pay a fixed fee for the software which would then be installed on their local machines. With Photoshop CC, Adobe introduced a subscription-based pricing model, allowing users to access the software without the initial hefty cost. Photoshop CC also allowed users to sync their Photoshop preferences to the cloud which was a first at the time.
It also brought an increase in security vulnerabilities from the prior years. The total vulnerabilities identified and patched from 1999 to 2019 stand at 3313 according to CVE. Most of these vulnerabilities were identified between 2013 to 2019 (2496 of them to be more precise).
Due to this, in recent years Adobe made some architectural changes to the whole cloud architecture and software stack as to better protect the users from this increasing number of vulnerabilities. As per Adobe, the current Cloud stack architecture is built with security considerations at its core, and utilizes industry standard software security methodologies for both development and management of the Creative Cloud.
Creative Cloud leverages multi-tenant storage in which customer content is processed by an Amazon Elastic Compute Cloud (EC2) instance and stored on a combination of Amazon Simple Storage Service (S3) buckets and through a MongoDB instance on an Amazon Elastic Block Store (EBS).
Creative Cloud is deployed regionally and each region contains two VPC (Virtual Private Cloud) instances, a Creative Cloud VPC and a Shared Cloud VPC. Both VPCs are logically isolated networks within an AWS region. The Creative Cloud VPC hosts the websites and APIs where end-users interact with the solution, and the Shared Cloud VPC hosts the services that perform common tasks across Creative Cloud, such as storage.
In practice, availability zones exist as isolated locations within a region. However, from a network architecture perspective, they reside in a VPC. Physically, each availability zone has multiple different redundant data centers, enabling all data to be replicated across all data centers as well as within multiple servers within each data center. This redundant backup ensures that Creative Cloud customer data is safe from disasters, floods, power failures, etc.
Everything within each VPC is locked down by an AWS Security group, represented by orange keys in the chart above. A security group is another layer of security that allows Adobe to control the inbound and outbound traffic through the VPC, much like a virtual firewall.
The actual code within the VPC is housed in Amazon EC2 instances in specific subnets (or ranges of IP addresses). While public subnets are connected to the internet, private subnets are not and are only accessible through authenticated connections originating from the public subnet. This prevents an unauthorized user from connecting directly to the Creative Cloud storage service, for example, and allows Adobe to make sure that only authorized users can perform certain actions, such as storing UGC.
UGC is stored in Amazon S3 buckets and the metadata about the content is stored in Amazon EBS via MongoDB. The UGC is then protected by Identity and Access Management (IAM) roles within that AWS region. Implementing per-user content security, IAM roles ensure that any content an end-user uploads to the cloud is considered private and is only accessible by that user, unless they take explicit steps to share it.
Content and assets stored in S3 are encrypted with AES 256-bit symmetric security keys that are unique to each customer and their claimed domain. The dedicated keys are managed by the Amazon Key Management Service (KMS), which provides additional layers of control and security for key management. Adobe automatically rotates the key on an annual basis. If necessary, IT administrators can revoke their key via the Admin Console, which will render all data encrypted with that key inaccessible to end-users.
Metadata and support assets are stored in EBS using AES 256-bit encryption and Federal Information Processing Standards (FIPS) 140-2 approved cryptographic algorithms, both of which are consistent with National Institute of Standards and Technology (NIST) 800-57 recommendations.
An example of user generated content data flow in the Adobe Creative Cloud cand be seen below:
  1. End-users store the content they create in a Creative Cloud folder on their system’s hard drive. If the user chooses to upload this content to cloud storage in Creative Cloud, a background process uploads the UGC to the cloud. All UGC is encrypted in-transit using AES 128-bit GCM over TLS 1.2.
  2. The Adobe Identity Service validates the user and their entitlements.
  3. Adobe Creative Cloud for enterprise scans the content for viruses and sends the content to the AWS Key Management System (KMS) for encryption.
  4. AWS KMS encrypts the user’s content with the customer-managed encryption key.
  5. Creative Cloud stores the encrypted content in AES 256-bit Amazon S3 storage. In order to update or retrieve the content, the user must use Creative Cloud; there are no external links to the content.
  6. Metadata about the content is stored in MongoDB on an Amazon EBS using AES 256-bit encryption.
User generated content is redundantly stored in multiple data centers within a region and on multiple devices in each data center. All network traffic undergoes systematic data verification and checksum calculations to prevent corruption and ensure integrity. Finally, stored content is synchronously and automatically replicated to other data center facilities within the customer’s region so that data integrity is maintained even in the event of data loss in two locations.
UGC created using Creative Cloud can be stored in the US (US-East VA), Europe (EMEA-West IE), or Japan (APAC-West JP) regions. An end-user’s regional data store is determined when the user is created in the Adobe Admin Console and remains consistent throughout the user’s lifetime. In other words, content created by a user account in the US will always be stored in the US data center, regardless of where the user is located when they upload the content.
As mentioned above, Adobe encrypts all UGC stored in Creative Cloud at rest. For an additional layer of control and security, IT administrators can enable a dedicated encryption key for some or all the domains in the organization. Content is then encrypted using that dedicated encryption key which, if required, can be revoked from the Admin Console. Revoking the key will render all content encrypted with that key inaccessible to all end-users and will prevent both content upload and download until the encryption key is re-enabled.
The key service employed utilizes FIPS 140-2 validated hardware security modules (HSMs) to protect key integrity and confidentiality. Plain-text keys are never written to disk and are only used in the HSM volatile memory on the server in the regional data store.

Recommended for you

If you liked reading this, you will enjoy those as well: