Important Update: Community URLs redirect issues are partially resolved. Learn More. .

cancel
Showing results for 
Search instead for 
Did you mean: 
Anonymous
Not applicable

Updated May 5, 2020 - CONFIDENTIAL

 

UPDATE:  A new FAQ page has been created specifically to address changes for the migration of Hosted Services in the EMEA data center (https://community.rsa.com/docs/DOC-112135). Please follow that page for ongoing updates.

 

The following FAQs have been provided as a supplement to the announcement that RSA Selects AWS for RSA Archer Hosted Services. This is a living document and will be added to as we receive additional questions.

 

WHAT, WHY, WHO AND WHEN

 

What company has RSA selected as the new data center and managed services provider?

RSA Archer has selected Amazon Web Services (AWS) as the new data center and managed services provider. AWS is an enterprise-class cloud service and software provider trusted by enterprises worldwide to migrate and run their mission-critical applications in the cloud. For more information about the company, visit aws.amazon.com.

 

Why is RSA Archer Hosting Services moving to AWS?

AWS has been selected because their world class service will allow us to provide greater scalability, flexibility and responsiveness, as well as advance our SaaS strategy.

 

Does this affect customers in both the US and EMEA data centers? (updated 2.22.19)

Yes, customers in both the US and EMEA data centers are affected. All Hosted customer data resides either on the US or EMEA data centers. Customers in both regions will be migrated from their current platform to AWS.

 

When will the migration occur? (updated 10.28.19)

Per the notification delivered to all Hosted Admins on Thursday, September 12th, the following dates were conveyed.

Testing

  • Testing
    • Non-Prod: Wednesday, Oct 9  Monday, Oct 14
    • Prod: Wednesday, Oct 16  Monday, Oct 28
  • Testing Complete
    • Non-Prod: Wednesday, Nov 6
    • Prod: Wednesday, Nov 13

 

Migration

  •  Non-Prod
    • Start: 8:00pm Central Time, Friday, Nov 8, 2019
    • End: 2:00am Central Time, Monday, Nov 10, 2019
  • Prod
    • Start: 8:00pm Central Time, Friday, Nov 15 2019
    • End: 2:00am Central Time, Monday, Nov 18, 2019

 

MIGRATION & TESTING

 

Is our data moving?

Yes, the primary facility and geographically redundant warm sites are both affected for all RSA Hosted customers.

 

Where specifically will our data be stored? (updated 7.16.19)

The following AWS Regions have been selected.

 

 

US

EMEA

Primary

Oregon (us-west-2)

EU Ireland

Backup

N Virginia (us-east-1)

EU Frankfort

 

What is the plan for the migration? (updated 7.16.19)

We have developed an approach that will allow you flexibility to test within the AWS environment, while at the same time minimize impact to your users and business processes.

Test Phase

During the Testing Phase, RSA will snapshot your existing non-production environment and mirror it in AWS. You’ll be able to test against that AWS environment, while your existing non-production environment continues to be available for your users and everyday work. On a separate date, we will snapshot your production environment and work through the same process. During this phase, we will ensure that outbound traffic, such as Notifications, will not occur. When the testing period has concluded, your test Instances will be deleted, as well as the provided AWS test URLs.

 

NOTE: These environments are for testing only and all activity, record creation, workflows, etc. will be deleted. You will not be able to save any work from the test environment for your future production environment.

 

Migration Phase

With the Migration Phase, your non-production Instance will be made inaccessible, a current snapshot will be taken and migrated to an AWS environment. On a separate migration date, we will perform the same process for your production Instance.

What are the Test URLs and IP Addresses? (updated 10.2.19)

ServiceIP Address
aws-test-grc.archer.rsa.com54.245.98.62

aws-test-grcb.archer.rsa.com

52.11.0.251

aws-test-ftp.archer.rsa.com

35.161.170.170

aws-test-sso.archer.rsa.com

52.40.43.172
irm01-mail01.archer.rsa.com54.200.217.100
Egress34.209.141.205
Egress34.214.108.160
Egress35.161.81.113
Egress35.166.207.202
Egress52.43.91.55
Egress54.71.62.175


How do we prepare?
(updated 10.10.19)

Understand crucial applications you may want to test after each step (non-prod and prod). Internally communicate the migration date and product non-availability time frames.

WARNING: Some customer configurations may have links that direct users back to content in the current environment. Testers should ensure that any actions they perform are occurring within the AWS environment. To assist with contextual reference, we have updated the tab name for all instances in the AWS Test environment. We further suggest that you update the color through the Appearances setting to make it extremely clear to a tester if they mistakenly navigate out of the AWS Test environment. The risk is in this scenario is that that they mistakenly make updates to your existing non-production, or worse, your production environment.

 

Specifics for Testing

How do we test? (updated 10.12.19)

The new URLs are provided above for both Non-Prod and Prod to test with during the Test Phase. While the amount of testing you perform is your choice, be aware that there will be no changes in features or functionality during the migration. You can perform basic actions like reviewing dashboards, running reports, creating records, searching, etc. As we are not changing functionality, the main focus should be on performance and response times. URLs will not change for the Migration Phase.

Can I test SSO? (added 11.5.19)

The SSO service is already sitting on AWS and references your existing URLs. That means that by signing into your live non-production and production instances on your existing environment using SSO, then you are testing SSO on AWS.  At the time of instance migration, the URLs associated with your existing environments will be pointed to your AWS environments. Since the SSO service looks at URLs, the transition will be seamless, with no changes needed from you. You can further test your SSO log-in for the applicable environments after each migration.

Can I test Notifications? (added 10.7.19)

Yes, you will be able to test Notifications. From the snapshot, we will delete all notifications from the queue and remove all emails from the contact records. You can enter an email addresses back to contact records as needed to test. (for customized email addresses see the KB article in the Notifications question below)

 

Can I test Data Feeds? (added 10.7.19)

Yes, you can test Data Feeds. We took precautions to mitigate possible risks of customers running data feeds that reach outside of Archer, possibly trying to access vendors from unknown whitelisted locations and causing serviceability issues, unexpectedly changing data from a testing location, etc. We deleted all jobs from within the queue and disabled all scheduled data feed jobs.

 

This means that no data feeds will be running in that environment, however, you can enable existing data feeds or establish new data feeds for testing, working with outside vendors as needed.

 

WARNING: Job parameters were not changed. For any existing jobs you enable, make sure you understand the impact prior to doing so. Examples include:

  • If you have a job that updates another Archer instance, the URL in the job parameter will not point to the AWS test environment, resulting in writing to an unintended instance.
  • Your job reaches out once a day to a vendor to get data. Your AWS test environment job connects to that vendor before your current environment jobs. Will the it be successful the second time. Does connecting multiple skew any type of vendor tracking in place?

 

What URL/FTP will I use? (added 10.7.19)

aws-test-ftp.archer.rsa.com, IP 35.161.170.170

 

Will credentials be intact? (added 10.24.19)

Yes, you will use the same credentials as today. Testing for SSO will be available Monday, November 4th.

 

Will encryption keys from the config database be synchronized between environments (added 10.7.19)

Yes, they have been synchronized between the two platforms.

 

During Testing, will all APIs be enabled? (added 10.7.19)

Yes

 

Can I test with my various integration partners? (added 10.7.19)

Yes, but be to avoid issues with your current test and/or production environment it’s suggested that you utilize different partner accounts to point to the test URLs.

 

Any other features turned off for Testing? (updated 10.7.19)

The only feature not readily available to test is Deep Linking for SSO (SSO for log-on is available).

 

Specifics for Migration

How long will we have to test between the non-production and production migration? (updated 10.2.19)

The time between the non-production and production migration is one week. The testing phase, which mirrors your environment, allows for three additional weeks of each environment.

 

Will our instance be inaccessible during the move and, if so, for how long?

While we are looking at ways to minimize the impact, customer data migrations will take place during weekend hours, at which times the Hosted Services are expected to be unavailable.

 

Will there be an upgrade during the migration? (updated 7.16.19)

No, the release version will not change during the migration.

Are there dedicated support specialists available to take my call during migration for support issues?

The RSA Archer Customer Support team will be fully versed and have access to the appropriate internal technical and operations associates to handle any issues that may occur during a customer’s migration.

 

Will anything change with the Customer Support model?

The Customer Support model will remain the same. RSA Archer Customer Support and/or your Designated Support Engineer will be your primary contact point. Questions or issues that need to go to the Operations or Engineering teams will be facilitated by your primary contact point.

Will the URLs that I use to access my Hosted instances change? (updated 7.16.19)

Previously, we anticipated that the production and non-production URLs for migration would change. In our effort to minimize impacts to you, we have taken steps to ensure that they will not change.

 

Existing US

Existing EMEA

Non-Prod

grcb.archer.rsa.com

grcb-eur.archer.rsa.com

Prod

grc.archer.rsa.com  

grc-eur.archer.rsa.com

Will the FTP URLs change? (update 11.22.19)

No, your FTP URLs will not change. 

Note: If you are using FTP for Archer to Archer data feeds you MUST use ftp://ftp01 to be successful. Previously, using ftp.archer.rsa.com would work, but was against standard advice. This is no longer the case.  

Will my SSO URLs change?

No, your SSO URLs will not change.

 

Will my vanity URLs change?

No, your vanity URLs will not change.

 

Will the SSH host key used for data feed file upload via SFTP change?

This is still to be determined. More details will be provided as they become available.

 

Will external IP addresses change? (updated 11.7.19)

Yes. RSA has always recommended using and monitoring fully qualified domain names instead of IP addresses for whitelisting functions, as this allows IP addresses to be seamlessly changed. These following external IP addresses have been reserved by use for RSA Archer, but are subject to change during future technical events. RSA Archer will publish customer communications for any planned changes.

US Hosted Non-Prod: 52.11.0.251

US Hosted Prod: 54.245.98.62

 

Will I need to change my Whitelists?

No, your customer designated whitelists will not change.

 

Do we need to make changes for Notifications?

If you have customized the “Default From Address” in the ACP, then you will need to make changes in your mail server. Review the Knowledge Based Article for more information. https://community.rsa.com/docs/DOC-58492

 

Will the RSA Archer version change as part of the migration?

No, the software version will not change during the migration.

  

SECURITY & COMPLIANCE

 

How do we ensure our data is secure? (updated 10.14.19)

The RSA Archer Hosted environments are controlled by the policies of Dell’s Compliance and Risk Management Organization. Dell’s Compliance and Risk Management Organization oversees and implements a formal enterprise-wide security risk assessment program which includes risk identification, classification, assessment, remediation and reporting. The policies address security controls such as access restriction, acceptable use, remote access, change control, information classification, third-party access, and physical security. To ensure the effectiveness of in-place controls and physical security safeguards, both RSA Archer and AWS regularly undergo 3rd party audits and certifications.

Are these RSA and AWS reports made available to customers? (updated 8.5.19)

RSA completes a SIG (Standardized Information Gathering) questionnaire, based on how security risks are managed. Included with the SIG is the most current SOC2 report and detailed instructions for obtaining a SOC2, Type II report from AWS. Contact your account team to obtain a copy.

Are there safeguards in place during the migration to ensure data is not lost, nor compromised? (updated 10.14.19)

Yes, we have security controls in place on both the existing and new environments, we encrypt data in transit and will securely delete data from the existing environment at an appropriate time after we successfully move to AWS.

Will our data on the existing platform be destroyed/returned to RSA after the migration? (added 11.7.19)

Yes. We are currently having conversations with the existing provider around the timing and process for data destruction. Given the current migration timeline, we anticipate having all data destroyed, using industry standards, by the end of this year.

  

SUPPORT

 

Will anything change with regard to RSA Archer services, service levels, and security obligations?

No, nothing will change with regard to the services, service level objectives, or industry standard security approaches of your RSA Archer Hosting Services.

 

What are you doing to ensure a successful migration?

The fundamental structure of AWS allows for more granular problem analysis, as well as the immediate ability to spin up new infrastructure to test out problem resolutions. This allows for a more robust testing and analysis approach prior to migration.

 

Do I have a new contract to sign?

No, changes in contracts will not be needed for the migration into the new AWS Hosted environment.

 

Will the cost of my Hosting Services change?

No, your hosting services costs will remain unchanged when you migrate to the new AWS environment.

 

Will the billing process change?

No, the existing billing process will remain unchanged.

 

After the migration, will the ongoing upgrade cadence change?

No, for all ongoing upgrades (after the migration has been completed) we will continue to follow the standard cadence of migrating to non-production first, followed two weeks later with a migration to production.

 

With a SaaS deployment, will you continue to develop and support on-premise customers?

Yes, RSA will continue to develop and deploy features for both on-premise and hosted customers.

  

FUNCTIONALITY

 

Do we get more direct control over our own instances?

While this does get us closer to allowing you to have more control over your instances, the initial migration does not provide additional controls. Your requests will still go through Customer Support as they do today.

 

Does this lift the restriction on allowing PII data in the Hosted environment?

No, this initial migration does not remove the restriction of allowing PII data into customer instances. Work has begun to engage a third-party auditor in understanding our next steps to remove this restriction.

 

Are there new AWS Services available to me to utilize?

Archer is supported in AWS (and Azure) as a Virtual Machine (VM).  Native services are not supported even though many RSA Archer customers are able to interact with various cloud native services today. While RSA is making progress toward coding against AWS native services for RSA Archer, we are not explicitly making available, nor supporting any native services at this time.

9 Comments
ScottByrum
Collaborator III

Can RSA confirm that SSO testing is enabled in the 2 test AWS environments?  Also, can you provide instructions for the simplest way to test that SSO is working?  We're hoping an internal Archer Admin with SSO access can simply click a URL rather than having to involve the team that manages the enterprise SSO technology.

 

Thanks!

MariWeiss2
Contributor III

I have the same question as Scott. We've not been successful testing SSO in the AWS Test environments, are there any updates that are not yet published on the FAQ?

 

Thanks!

ScottByrum
Collaborator III

Hi Mari,

 

Looks like this thread answers our question: https://community.rsa.com/docs/DOC-108799 

 

My interpretation is: if, on 11/5/19, users successfully used SSO to access your existing environments (not the AWS environments) you're all good!

 

Scott

Anonymous
Not applicable

Scott that's correct. And for further validation, after the migration this weekend, try logging into your non-production environment using SSO.

Anonymous
Not applicable

Mari, trying to test SSO prior to the migration has led to a number of challenges due to unique difference in customer's deployments. As mentioned in the notification referenced by Scott, with the SSO component already moved to AWS, signing on with SSO to your existing instances verifies the functionality. After the migration this weekend, when you use SSO to sign into the non-prod environment will be going against your new AWS environment.

MariWeiss2
Contributor III

Great, thanks so much for the information!

AMITMURUMKAR
Contributor II

Has the SSO worked for your non-prod environments as expected (AWS )? We use SSO only in our PROD so trying to figure out if everything was smooth as expected or if there were any issues to that I should be aware of.

MichaelFuller
Contributor

What is the new external IP address for FTP?

Anonymous
Not applicable

Michael, the IP Address for FTP is 35.161.170.170.  I will add this detail to the FAQs.