Framework/Configurations/SVT/Services/ServiceFabric.json

{
  "FeatureName": "ServiceFabric",
  "Reference": "aka.ms/azsdkosstcp/servicefabric",
  "IsManintenanceMode": false,
  "Controls": [
    {
      "ControlID": "Azure_ServiceFabric_AuthN_Publicly_Expose_MicroSrvc_AuthN_And_AuthZ",
      "Description": "Publicly exposed microservice endpoints must have authentication and authorization enforced",
      "Id": "ServiceFabric110",
                         "ControlSeverity": "High",
      "Automated": "No",
      "MethodName": "",
      "Recommendation": "As per business requirements, access control must be implemented on publicly exposed microservices using standard/usual methods.",
      "Tags": [
        "SDL",
        "TCP",
        "Manual",
        "AuthN"
      ],
      "Enabled": true
    },
    {
      "ControlID": "Azure_ServiceFabric_DP_Exposed_Endpoint_SSL_Secured",
      "Description": "Publicly exposed endpoints must be secured using SSL",
      "Id": "ServiceFabric120",
                         "ControlSeverity": "High",
      "Automated": "No",
      "MethodName": "",
      "Recommendation": "Azure Service Fabric supports configuration of endpoints for microservice.To provide end to end encryption and data integrity, all publicly exposed endpoints must be secured using SSL. Steps to configure SSL: 1.Specify HTTPS endpoint in ServiceManifest.xml at ServiceManifest -> Resources --> Endpoints 2.Specify certificate details in ApplicationManifest.xml i> Add an�EndpointBindingPolicy�at ApplicationManifest -> ServiceManifestImport -> Policies ii> Add an�EndpointCertificate� at ApplicationManifest -> Certificates 3.Upload certificate to cluster (For detailed steps to configure HTTPS endpoint and certificate details, refer Azure article https://azure.microsoft.com/en-in/documentation/articles/service-fabric-service-manifest-resources/#example-specifying-an-https-endpoint-for-your-service )",
      "Tags": [
        "SDL",
        "TCP",
        "Manual",
        "DP"
      ],
      "Enabled": true
    },
    {
      "ControlID": "Azure_ServiceFabric_DP_App_Secrets_Cert_Encrypted",
      "Description": "Application secrets must be encrypted with certificate",
      "Id": "ServiceFabric130",
                         "ControlSeverity": "High",
      "Automated": "No",
      "MethodName": "",
      "Recommendation": "An application typically contains secrets, such as connection string, storage account keys, password etc., which are required at runtime. Application secrets can be stored in Settings.xml file in ConfigPackage of microservice, ServiceManifest.xml and ApplicationManifest.xml. These secrets must be encrypted with certificate. Steps to encrypt a secret: 1.Obtain a data encipherment certificate.2.Install the certificate on cluster.3.Encrypt secret values when deploying an application with the certificate and inject them into Settings.xml/ServiceManifest.xml/ApplicationManifest.xml file. 4. Read encrypted values out of Settings.xml by decrypting with the same encipherment certificate. For implementation details of above steps, refer Azure article https://azure.microsoft.com/en-us/documentation/articles/service-fabric-application-secret-management/",
      "Tags": [
        "SDL",
        "TCP",
        "Automated",
        "DP"
      ],
      "Enabled": true
    },
    {
      "ControlID": "Azure_ServiceFabric_DP_Data_Replication_Cert_Secured",
      "Description": "Data replication must be secured with certificate",
      "Id": "ServiceFabric140",
                         "ControlSeverity": "Medium",
      "Automated": "No",
      "MethodName": "",
      "Recommendation": "Service Fabric replicator service is responsible for making the state of Stateful service highly reliable. Replicator security configurations must be used to secure the communication channel that is used during replication. This means that services will not be able to see each other's replication traffic, ensuring that the data that is made highly available is also secure. By default, an empty security configuration section prevents replication security.For more details about replicator security configuration, refer �Sample configuration file� section in Azure article https://azure.microsoft.com/en-in/documentation/articles/service-fabric-reliable-services-configuration/#_replicator-security-configuration",
      "Tags": [
        "SDL",
        "TCP",
        "Automated",
        "DP"
      ],
      "Enabled": true
    },
    {
      "ControlID": "Azure_ServiceFabric_DP_Sensitive_Data_Dont_Store_In_DataPackage",
      "Description": "Sensitive data must not be stored inside DataPackage",
      "Id": "ServiceFabric150",
                         "ControlSeverity": "High",
      "Automated": "No",
      "MethodName": "",
      "Recommendation": "DataPackage is intended to store static files which are required by microservices at runtime. Files inside DataPackage are NOT intended to be modified at runtime.DataPackage must not contain any file containing sensitive data, because: 1. DataPackage files can be accessed from other microservices running on same node (VM).2.DataPackage files gets distributed along with the application package while publish.",
      "Tags": [
        "SDL",
        "TCP",
        "Automated",
        "DP"
      ],
      "Enabled": true
    },
    {
      "ControlID": "Azure_ServiceFabric_Availability_Replica_Stateful_Size_Set_Min_3",
      "Description": "Replica set size for stateful services must be set to minimum 3",
      "Id": "ServiceFabric160",
                         "ControlSeverity": "Medium",
      "Automated": "No",
      "MethodName": "CheckStatefulServiceReplicaSetSize",
      "Recommendation": "The replica set size of a Stateful service indicates the number of copies of reliable service data maintained by Service Fabric. The data in reliable service must not be lost even if a node (VM) goes down. However, if the replica set size is 1, data loss is possible.To achieve high availability, each stateful service must have a target and minimum replica set size of at least 3. Set the values for all Stateful services in ApplicationManifest.xml file as below: 1. ApplicationManifest -> DefaultServices -> Service -> StatefulService -> MinReplicaSetSize 2. ApplicationManifest -> DefaultServices -> Service -> StatefulService -> TargetReplicaSetSize For more details on replica set size, refer Azure article. https://azure.microsoft.com/en-in/documentation/articles/service-fabric-concepts-partitioning/",
      "Tags": [
        "SDL",
        "TCP",
        "Manual",
        "Availability"
      ],
      "Enabled": true
    },
    {
      "ControlID": "Azure_ServiceFabric_Availability_Instance_Stateless_Size_Set_Min_3",
      "Description": "Instance count for stateless service must be set to minimum 3",
      "Id": "ServiceFabric170",
                         "ControlSeverity": "Medium",
      "Automated": "No",
      "MethodName": "",
      "Recommendation": "An instance count is the number of instances of the stateless service that should be running in the cluster. This is the number of copies of the application logic that will be instantiated in the cluster. Stateless service must be available even if a node (VM) goes down. However, if the instance count is 1, service may not be available. To achieve high availability, each stateless service must have an instance count of at least 3. Set the value for all stateless services in ApplicationManifest.xml file at ApplicationManifest -> DefaultServices -> Service -> StatelessService -> InstanceCount",
      "Tags": [
        "SDL",
        "TCP",
        "Manual",
        "Availability"
      ],
      "Enabled": true
    },
    {
      "ControlID": "Azure_ServiceFabric_BCDR_Stateful_Micro_Srvc_Geo_Redundant_Stg_Acc",
      "Description": "Stateful microservices must be backup to geo-redundant Storage Account",
      "Id": "ServiceFabric180",
                         "ControlSeverity": "Medium",
      "Automated": "No",
      "MethodName": "",
      "Recommendation": "Stateful microservices loose their state when: 1.Application gets redeployed due to changes in manifest files. e.g. change in partition count, change in endpoint configuration etc. 2.An entire physical data center is destroyed. To protect against data loss, it is critically important to periodically�backup Stateful microservices�to a geo-redundant store. Stateful microservices maintains their state in reliable collections. Reliable collections must be backup to and recovered from geo-redundant Storage Account.To implement backup and restore of reliable collections, please refer Azure article https://azure.microsoft.com/en-in/documentation/articles/service-fabric-reliable-services-backup-restore/",
      "Tags": [
        "SDL",
        "TCP",
        "Automated",
        "BCDR"
      ],
      "Enabled": true
    },
    {
      "ControlID": "Azure_ServiceFabric_AuthZ_Security_Mode_Enabled",
      "Description": "Service Fabric cluster security must be enabled using security mode option",
      "Id": "ServiceFabric190",
                         "ControlSeverity": "High",
      "Automated": "Yes",
      "MethodName": "CheckSecurityMode",
      "Recommendation": "A secure cluster must be created to prevent unauthorized access to management operations, which includes deployment, upgrade, and deletion of microservices. A secure cluster also provides encryption for node-to-node communication, client-to-node communication etc. An unsecure cluster is open to be connected by any anonymous user. An unsecure cluster�cannot be secured at a later time. For creating a secure cluster using 1. Azure Portal, refer steps at this Azure article https://azure.microsoft.com/en-in/documentation/articles/service-fabric-cluster-creation-via-portal/#_3-security 2. ARM template,refer steps at this Azure article https: //azure.microsoft.com/en-in/documentation/articles/service-fabric-cluster-creation-via-arm/",
      "Tags": [
        "SDL",
        "TCP",
        "Automated",
        "AuthZ"
      ],
      "Enabled": true
    },
    {
      "ControlID": "Azure_ServiceFabric_AuthZ_Microservice_Trust",
      "Description": "Service Fabric cluster must contain microservices which trust each other",
      "Id": "ServiceFabric200",
                         "ControlSeverity": "High",
      "Automated": "No",
      "MethodName": "",
      "Recommendation": "Microservice hosted on same Service Fabric cluster can monitor traffic of other microservices and access the files hosted on cluster. Hence a Service Fabric cluster must contain the microservices which trust each other.",
      "Tags": [
        "SDL",
        "TCP",
        "Automated",
        "AuthZ"
      ],
      "Enabled": true
    },
    {
      "ControlID": "Azure_ServiceFabric_AuthN_Self_Signed_Cert",
      "Description": "Self-signed certs must not be used for Service Fabric cluster primary certificate",
      "Id": "ServiceFabric210",
                         "ControlSeverity": "High",
      "Automated": "Yes",
      "MethodName": "CheckClusterCertificateSSL",
      "Recommendation": "Service Fabric uses X.509 certificates that can be specified while creating a cluster. The primary certificate is required to secure a cluster and prevent unauthorized access to it. It provides cluster security in a couple ways: 1. Cluster authentication:�Authenticates node-to-node communication. 2. Server authentication:�Authenticates the cluster management endpoints to a management client. The primary certificate also provides SSL for the HTTPS management API and for Service Fabric Explorer over HTTPS. Primary certificate, which is also used for SSL, must be obtained from an approved Certificate Authority [SSLAdmin].Note : You cannot obtain an SSL certificate from a certificate authority (CA) for the��.cloudapp.azure.com��domain. You must acquire a custom domain name for your cluster. When you request a certificate from a CA the certificate's subject name must match the custom domain name used for your cluster.",
      "Tags": [
        "SDL",
        "TCP",
        "Automated",
        "AuthN"
      ],
      "Enabled": true
    },
    {
      "ControlID": "Azure_ServiceFabric_AuthN_Client_AuthN_AAD_Only",
      "Description": "Client authentication must be performed only via Azure Active Directory",
      "Id": "ServiceFabric220",
                         "ControlSeverity": "High",
      "Automated": "Yes",
      "MethodName": "CheckAADClientAuthentication",
      "Recommendation": "A Service Fabric cluster offers several entry points to its management functionality, including the web-based�Service Fabric Explorer,�Visual Studio and PowerShell. Access to the cluster must be controlled using AAD. For detailed steps to configure AAD for client authentication using ARM template, refer steps at this Azure article https://azure.microsoft.com/en-in/documentation/articles/service-fabric-cluster-creation-via-arm/#_set-up-azure-active-directory-for-client-authentication",
      "Tags": [
        "SDL",
        "TCP",
        "Automated",
        "AuthN"
      ],
      "Enabled": true
    },
    {
      "ControlID": "Azure_ServiceFabric_DP_Set_Property_ClusterProtectionLevel",
      "Description": "The property \"ClusterProtectionLevel\" must be set to \"EncryptAndSign\"",
      "Id": "ServiceFabric230",
                         "ControlSeverity": "High",
      "Automated": "Yes",
      "MethodName": "CheckClusterProtectionLevel",
      "Recommendation": "Service Fabric provides three levels of protection (None, Sign and EncryptAndSign) for node to node communication using cluster primary certificate. The protection level can be specified using property 'ClusterProtectionLevel' inside Service Fabric ARM template. The value of 'ClusterProtectionLevel' must be set to 'EncryptAndSign' to ensure that all the node-to-node messages are encrypted and digitally signed. Configure 'ClusterProtectionLevel' using ARM template ARM Template -> Resources -> Select resource type 'Microsoft.ServiceFabric/clusters' -> 'fabricSettings' -> Add 'ClusterProtectionLevel' property with value 'EncryptAndSign'.",
      "Tags": [
        "SDL",
        "TCP",
        "Automated",
        "DP"
      ],
      "Enabled": true
    },
    {
      "ControlID": "Azure_ServiceFabric_AuthN_NSG_Enabled",
      "Description": "Network security group (NSG) must be enabled on subnets of Service Fabric cluster",
      "Id": "ServiceFabric240",
                         "ControlSeverity": "Medium",
      "Automated": "Yes",
      "MethodName": "CheckNSGConfigurations",
      "Recommendation": "NSG contains a list of Access Control List (ACL) rules that allow or deny network traffic to Service Fabric node instances in a Virtual Network. NSGs can be associated with either subnets or individual node/VM instances within a subnet. NSG must be used in following scenarios: 1. Restrict RDP connection only from admin machine IP 2. Restrict microservice incoming request from trusted source IP 3. Lock down the remote address ranges allowed for microservice deployments�For more detailed implementation, refer Azure article https://azure.microsoft.com/en-in/documentation/articles/virtual-networks-create-nsg-arm-pportal/",
      "Tags": [
        "SDL",
        "TCP",
        "Automated",
        "AuthN"
      ],
      "Enabled": true
    },
    {
      "ControlID": "Azure_ServiceFabric_DP_Enable_Encryption_Stg_Acc_Store_VHD",
      "Description": "Encryption must be enabled on all storage accounts which stores VHD of Service Fabric cluster VMs",
      "Id": "ServiceFabric250",
                         "ControlSeverity": "High",
      "Automated": "Yes",
      "MethodName": "CheckStorageEncryption",
      "Recommendation": "Encryption must be enabled on all storage accounts, which store VHDs of the Service Fabric cluster VMs, for Encryption of underlying OS and data disks for IaaS VMs created using Service Fabric nodes. Enable storage account encryption for all storage accounts, which stores VHD of Service Fabric cluster VMs, using Azure Portal :Portal -> Storage Accounts -> <Storage Account Name> -> Encryption -> Set 'Server-side encryption' to 'Enabled'.",
      "Tags": [
        "SDL",
        "TCP",
        "Automated",
        "DP"
      ],
      "Enabled": true
    },
    {
      "ControlID": "Azure_ServiceFabric_Audit_Use_Diagnostics_Log",
      "Description": "Diagnostics must be enabled for Service Fabric cluster",
      "Id": "ServiceFabric260",
                         "ControlSeverity": "Medium",
      "Automated": "Yes",
      "MethodName": "CheckVmssDiagnostics",
      "Recommendation": "Diagnostics must be enabled to get logs of these events- Service Fabric events:�Emitted by the platform to standard ETW and event source channels.�E.g. Node Down/Up etc.Application events:�Events emitted from the microservice code. E.g. Application Created, Service created/deleted etc. Diagnostics extension must be deployed on all VMs in the Service Fabric cluster. It collect logs from all the VMs and upload them to the Azure Storage Account. Enable Diagnostics while creating Service Fabric using 1. Azure Portal, refer Azure article https://azure.microsoft.com/en-in/documentation/articles/service-fabric-diagnostics-how-to-setup-wad/#_deploy-the-diagnostics-extension-as-part-of-cluster-creation-through-the-portal 2. ARM Template, refer Azure article https://azure.microsoft.com/en-in/documentation/articles/service-fabric-diagnostics-how-to-setup-wad/#_deploy-the-diagnostics-extension-as-part-of-cluster-creation-by-using-azure-resource-manager",
      "Tags": [
        "SDL",
        "TCP",
        "Automated",
        "Audit"
      ],
      "Enabled": true
    },
    {
      "ControlID": "Azure_ServiceFabric_Audit_Publicly_Exposed_Load_Balancer_Ports",
      "Description": "Monitor publicly exposed ports on load balancers used by Service Fabric cluster",
      "Id": "ServiceFabric270",
                         "ControlSeverity": "Medium",
      "Automated": "No",
      "MethodName": "",
      "Recommendation": "Azure load balancer maps the public IP address and port number of incoming traffic to the private IP address and port number of the Service Fabric nodes (ports number opened by microservices).Intranet microservice ports must not be exposed and publicly exposed IP address/port numbers must be monitored using Azure load balancer rules. Monitor all load balancing rules using Azure Portal : Portal -> Load Balancers -> <Load Balancer Name> -> Load Balancing Rules -> Validate mapping of public end port with backend port.",
      "Tags": [
        "SDL",
        "TCP",
        "Automated",
        "Audit"
      ],
      "Enabled": true
    }
  ]
}