Item 26 - Agreement with Allied Network Solutions, Inc. for Adobe Software and Subscription

Home Browse Search

SOLICITATION # CH16012 FireEye High-level architecture diagrams following industry best practices utilizing both virtual and physical controls are available and contained in the SOC 2 report. VirtueStream Virtustream utilized a virtual local area network (VLAN) and virtual route forwarding (VRF) to logically segregate all customers in the IaaS environment. Every customer chooses their own IP Address range, as there is no ability to overlap IP Addresses between customers. In addition, every customer is logically separated with Firewall Context with their own rule, where by default everything is denied except specific rule. 8.6.10 Provide Security Technical Reference Architectures that support Infrastructure as a Service (laaS), Software as a Service (SaaS) & Platform as a Service (PaaS). CA APM Only SaaS is provided, network diagram can be provided upon signing NDA MAA Only SaaS is provided, network diagram can be provided upon signing NDA CAAgile These can be provided when a NDA is in place. ASM Only SaaS is provided, network diagram can be provided upon signing NDA Salesforce Salesforce offers market leading PaaS and market leading SaaS solutions. Salesforce does not provide IaaS as a direct service offering to our customers, it is an underlying part of our PaaS and SaaS offerings. The Salesforce Platform is built for cloud computing, with multitenancy inherent in its design. To meet the high demands of its large user population, Force.com's foundation is a metadata-driven software architecture that enables multi -tenant applications. Force.com combines several different persistence technologies, including a custom -designed relational database schema, which are innately designed for clouds and multitenancy—no virtualization required. Force.com's core technology uses a runtime engine that materializes all application data from metadata—data about the data itself. In Force.com's well-defined metadata-driven architecture, there is a clear separation of the compiled runtime database engine (kernel), tenant data, and the metadata that describes each application. These distinct boundaries make it possible to independently update the system kernel and tenant -specific applications and schemas, with virtually no risk of one affecting the others. Every logical database object that Force.com exposes is internally managed using metadata. Objects, (tables in traditional relational database parlance), fields, stored procedures, and database triggers are all abstract constructs that exist merely as metadata in Force.com's Universal Data Dictionary (UDD). For example, when you define a new application object or write some procedural code, Force.com does not create an actual table in a database or compile any code. Instead, Force.com simply stores metadata that the system's engine can use to generate the virtual application components at runtime. When you need to modify or customize something about the application schema, like modify an existing field in an object, all that's required is a simple non - blocking update to the corresponding metadata. Because metadata is a key ingredient of Force.com applications, the system's runtime engine must optimize access to metadata; otherwise, frequent metadata access would prevent the service from scaling. With this potential bottleneck in mind, Force.com uses massive and sophisticated metadata caches to maintain the most recently used metadata in memory, avoid performance -sapping disk 1/0 and code recompilations, and improve application response times. carahsoft 89 carahsoft