goteamepsilon / openemr-cloud Goto Github PK

Inspiration: https://github.com/openemr/product_registration#deploy

This will be important and I always had trouble understanding this at work.

BTW technically Elastic Beanstalk is not HIPAA certified, but on all the forums they are saying you just have to configure it a certain way and then it is, because the underlying services are HIPAA compliant.

https://aws.amazon.com/compliance/hipaa-eligible-services-reference/

Network security is composed of:

• Creating the VPC (you'll already have on by default for you though)
• Create subnets for each availability zone. Create separate subnet for Database.
• Configure route tables of subnets
• Attach ACLs to those subnets (security step!)
• Attach a Security Group to each of the instances (all instances can share the same SG or use different ones, unless it's the DB) (security step!)
• Creation of VPN Gateway (optional I guess? if we do this they will have to do some manually set-up on premise I believe...maybe we can just use SSL, which is covered in another issue)

I am going to leave this open for you guys. It's very important to know. I know most of this other than the VPN part, since VPCs is like 60% of the AWS test...

How do I access the logs?
How do I configure and see my backups?
How do I make changes to my OpenEMR instance and redeploy it to my cloud?
How do I add other system users?
How do I access the database?

Set up a very manual step-by-step guide, just like Matt did for EFS. These will make it really easy to write the CloudFormation templates later.

This guide will include stuff like creating a non-root main account, turning on MFA, creating other users, and creating the KMS keys.

I was wrong... OpenEMR does have emailer support: http://open-emr.org/wiki/index.php/Sms_and_Email_Notification_Howtos

Very useful feature. I'd like to get version 1 of the guide of the door, so let's put this on version 2.

Here are the steps IMO. A lot could definitely have been left out though. Also Matt I put you on this because that 3rd step I'm not sure how it's going to work. How is Elastic Beanstalk going to know where to put the PHP app exactly? Stuff like that:

1. Create custom AMI
2. Share AMI on the marketplace.
3. Use the custom image as environment for Elastic Beanstalk

**NOTE: Looks like the base image has to be a specific Elastic Beanstalk AMI that's available in EC2 that you customize from?

To create a custom AMI, launch an Elastic Beanstalk platform AMI in Amazon EC2, customize the software and configuration to your needs, and then stop the instance and save an AMI from it.

Can you all sign up for this Slack group? They are really good: https://og-aws-slack.lexikon.io/

I get a lot of pushback because I'm from Oracle (oh no we destroyed Hudson which forced the community to create Jenkins which is in fact a lot better!), so it would help for some of our really tough questions.

Hi Team Epsilon,

To start with, thanks a lot for this tutorial and template to install OpenEMR in a breeze.
I followed the tutorial for N.Virginia on my AWS account(Free tier). However, in the mid of progress it got rolled back because of this issue:

15:54:00 UTC-0400 | CREATE_FAILED | AWS::ElasticBeanstalk::Environment | EBEnvironment | No Solution Stack named '64bit Amazon Linux 2017.03 v2.4.1 running PHP 7.0' found.

Once this event failed, the entire stack got rolled back.

Currently the Redis security group lets in inbound requests from 0.0.0.0/0, which is bad. We need to find a way to lock it down to only the EBS IP(s) (maybe 10.0.0.1-10.0.0.9 range?)

If you want costs to be as near-zero as possible for developing countries we will need to have a guide for deploying IaaS...perhaps all on the same instance.

However maybe we should ignore that for now on AWS...Google Cloud is the best solution for "absolutely low as possible costs"...I've heard this repeatedly from developers in Eastern Europe and the Philipines...they have some instances that are "always free" and other good discounts.

Just want you to be aware that as of now I am starting with the mindset that our solution will be deployed with a US-based hospital who needs everything HIPAA requires and can probably spend at least $100 a month (maybe more).

So this will be interesting. After all the user stuff has been created, we need to somehow get a copy of the latest version of the PHP code into S3...then Beanstalk can use it (see below screenshot).

• Option $1: just upload the correct source code to our own public S3 bucket and let whoever use that...might eventually have to use API Gateway or something to limit the requests so we don't get spammed. EASY

• Option $2: use the cloudformation template to spin up a quick machine that runs a "wget command"...copies the data into S3...then deletes itself. HARD

• Option $3: UNKNOWN

Hey Jeffrey:

• Per our Slack convo I created this issue just to track what you can work on ability-wise / what you'd like to work on.
• Maybe I'm projecting too much here, but the biggest issue starting out for me was I would see these vague issues and be like "wtf am I supposed to do with that".
• I would like these issues / tasks assigned to you to be very clear in how they can be achieved and shorter too...kind of like a quest you'd take in an RPG if you only had an hour left before bed.

1. Comment below on any IT skills you are good at / can do
2. Comment below on any IT skills you want to learn more about

@MatthewVita also after you respond Jeffrey, Matt we can take a look and maybe there is another OS project we can start in parallel that matches to Jeffrey's skills? Or maybe just work on Version 2.0 of this since @Jeffrey-P-McAteer I think you said you know Docker which I AM THE WORST AT.

We should use the linux tarball here: http://open-emr.org/wiki/index.php/OpenEMR_5.0.0_Linux_Installation

It is important to ensure the following values are in place: http://www.open-emr.org/wiki/index.php/FAQ#What_are_the_correct_PHP_settings_.28can_be_found_in_the_php.ini_file.29.3F

Use the following as inspiration: http://open-emr.org/wiki/index.php/OpenEMR_System_Architecture#OpenEMR_Dependencies

see openemr/openemr#572

https://aws.amazon.com/marketplace/pp/B00AJZJVNS

We need to find a CouchDB solution that works/scales on AWS. Also needs to be HIPPA compliant and highly available.

By end of May at latest!!!!

1. Finish AWS Security Course
2. Determine the AWS Users We Need / Permissions They Need
3. Complete IAM Draft Guide (it's another issue)
4. Figure out how to do AWS Scripting (it's in the Certified Developer Course)
5. Either go onto next topic or actually write out CloudFormation Script for IAM

I started using Asana with a friend. I realize we don't have a great task management (I hesitate to use the word "project" here).

I would like something, like Asana, where we can all of my tasks, all of XYZ person's tasks, and then maybe joint-mini-project tasks.

The real benefit here is that 1) It's easy for me to see what's my responsibility and what I'm working on and 2) There is a motivation aspect right to it. Issues describe problems, but tasks describe clear solutions / things that need to be done and made.
Also it's cool that you can see that I "did stuff" even if that "stuff" didn't result in a commit or closing out an issue.

Questions:

1. How is task management done at your job Matt? Is it all via issue assignment?
2. Not really a question but...I'm going to look into creating this. I know specifically Asana integrates with Slack (without even requiring Zapier).

Asana and Github integration is actually possible via Zapier: https://zapier.com/zapbook/asana/github/
Example screenshot of Asana:

http://open-emr.org/wiki/index.php/Patient_Portal

I've never messed around with the portal. We need to make sure it works with our solution!

WAF is Web Application Firewall...it's a Layer 7 firewall

You can get an SSL Cert from AWS so it should be pretty easy to automate that process too

Will periodically update this issue with easy-to-understand explanations of the various security services in AWS that we will use (maybe move this into a wiki at some point??). If you look on AWS you can find these services under "Management Tools" and "Security, Identity, and Compliance".

Config - define rules that you want your account to meet and see very easily whether or not you meet them. AWS has some OOTB rules as well as custom rules you can write (plus you add on Lambda functions to do the evaluation if you want!!)

So we'll be using the Amazon Linux AMI. Probably the most common one people use.
Look at the questions below. Eventually Jeffrey you'll find a way to secure/harden the instance, and then I guess 1). I can write a bash script for it / incorporate it in the CF template? Or 2). Maybe we'll make our own AMI?

Questions:

• Does this default AWS Linux AMI instance need to be hardened?
• If so how?
• Are you supposed to mess with the IPTables since I'm already creating security groups, ACLs, VPNs, etc?
• How does patching work? I think the instance just auto-updates? Does that change if we harden it?
• Should we use one of the hardened Linux images on the marketplace? I see some on there for 1 cent and 2 cent an hour.
• I know when I was reading the OpenEMR guide it had some good things (maybe they are really obvious to you though) to do. One of them was restricting access to the Apache Logs file. Another one was configuring of Apache.
• Should we even be using Apache? What about nginx?
• other stuff...

This will be the DB instance that OpenEMR uses to maintain it's basic operating and configuration data...it does not really store patient documents I believe.

How should you secure the RDS instance?
There is networking stuff that other issues will take care of...but is there anything else?
How is encryption handled?
How are the backups protected?
Should create roles for the EC2 instances to access the DB?
Are there any other weird IAM users we should have specifically for the DB?
Should we use SSL for connecting to the DB? Even if it's just the app server connecting behind the scenes to DB server?
How should the DB be accessed for maintenance? A Bastion instance? VPN? SSH?
Anything else?

End State Goal:

• Have a txt document that describes in steps, say 1-30 or something, exactly how to set up install and then secure an RDS instance. AWS will change so doesn't have to be exact exact...
• You can leave the network stuff (subnet, security groups, etc) blank for now or put that in if you want
• Eventually document will be used for a guide and then orchestration templates so keep that second point in mind :)

Check this out: https://aws.amazon.com/blogs/devops/use-nested-stacks-to-create-reusable-templates-and-support-role-specialization/

So a "nested stack" is what makes CloudFormation scripts really reusable. I haven't studied them in-depth yet, but these will be where the variables that need to be user-defined will be entered. I'm not sure exactly what these are going to be, but some things that come to mind might be:

• which region do you want?
• passwords for certain services
• ?
• ?
• ?

TASK: determine which variables need to be user defined
NOTE: I might revise this as I learn more about CF but I like Github issues it shows progress and my thought patterns

This will be a first pass at putting together all of our hard work thus far!

With respect to the "steps" that @danielehrlich has been noting, we need to use markdown and attention to detail to make sure the guide is a seamless process for our users!

Goals

• It should be obvious from the summary who is the intended user. I think the current summary is good for the most part.
• Team Epsilon's main goal is to get this document checked into OpenEMR with each release. I'm sure the community will even accept our ALPHA version guide! (EDIT: Note that the artifact doesn't have to be just the guide... we can create a deployment folder in OpenEMR proper and inside of it will be aws and k8s. We can check in scripts and other assets as needed.)

Attention to Detail

• Just like our Angular to React/Redux guide, we need to be very exact and concise with our wording.
• Perfect English is a must.
• Must be consistent (don't say "click" in some places and "hit" in other places).
• Keep American English idioms/expression out of the guide. For example, "By doing so, the server state will be adjusted on the fly" makes 0 sense to most of the world :). It is important to keep in mind that folks may even run our guide through Google Translate! Moreover, this guide may even be translated (OpenEMR has users all over the world with 30+ languages). Esto es emocionante!
• Don't do too much in one step... just like with QA test cases, it is best to split up steps into single actions.

Tone

• Writing tone should be positive and helpful... consider that the end user running the steps may not be technical! For example, instead of saying "SSH into the Redis node", break it up into several steps explaining how this is done and note that the goal would be "Configuring the Redis server so that logged in users can have an OpenEMR session". We won't be able to avoid using technical jargon everywhere because this stuff is inherently technical! However, an effort should be made to keep it straightforward.
• The user is expected to have basic computer literacy. We don't have to say things like "single click the link" or anything like that.

Organization

• Listing out steps 1 through 9999 is super intimidating and error prone. We need to use markdown and various stylings to make the steps a bit more consumable (i.e.: make use of sections and indentation within ordered lists). We won't be able to avoid the fact that the steps MUST be followed in order, but we can still make it easier to run down.
• Use Emojis for each section like we did with the Angular to React/Redux guide. This was well received and added context and flavor to each section.
• Make sure it is noted that this is an ALPHA release and to use it at your own risk.
• Make sure to note a summary somewhere about release 2 where we will be HIPAA/BAA compliant.
• Make sure to note somewhere that release 3 will be completely automated and can run on any platform (e.x.: Google or local cloud).

Cost

• While there are no guarantees, we should empower the user to select what kind of system size they want, relative to their use case. For example, we don't want a small clinic user picking the large multi AZ RDS database! $$$.

Administration

• Have a section about administrating the system... should answer the questions:
  • How do I access the logs?
  • How do I configure and see my backups?
  • How do I make changes to my OpenEMR instance and redeploy it to my cloud?
  • How do I add other system users?
  • How do I access the database?

Bash script out step 18 - 20 of https://github.com/GoTeamEpsilon/OpenEMR-AWS-Guide/blob/master/Other/MRV_working_guide.MD#redis-sessions

It would be great if the user could just copy and execute a bash script. The tricky part in doing this is using Linux tooling (hint: grek, sed, sed) to find the bind statement and comment it out.

I am thinking Elastic Beanstalk, RDS, Route53, IAM, TurnKey CouchDB, Cloudwatch, CloudFormation, and SES... is this a good selection? Am I missing anything?

Currently we're only supporting ./sites/default/**, but it should be ./sites/$VAR/**. Not a huge deal for version 1 and I've heard this feature isn't super well-used (one can just create another facility for a separate physical site or unit within an institution).

We should get this working eventually, but it's definitely on the bottom of our list!

This is pretty straightforward. We need a section for the admin user to SSH into Redis. We need to make sure inbound port 22 is opened up.

It is obviously bad to leave port 22 open all of the time to the world, so we need to note how to tweak the security group to either a) not have 22 open unless you need to get in or b) ONLY allow a specific IP address in (i.e.: that of the admin user's computer). Either approach is good in terms of security!

At some point we should have forecasted pricing guides so that organizations can make their own decisions. Like if you implement these services with this much data you will spend XYZ amount.

Also having different configuration "tiers" would be good as well:

• So the lowest tier would be for very poor world areas that just need the bootstrapped version, and probably don't have lots of end users accessing the system due to not everyone having internet.
• Then made a "middle" tier for 2nd world countries, e.g. Eastern Europe. In these countries pricing is definitely still a concern but they have very good internet so HA and security are going to be important.
• Then high tier which is everything you could possibly want...good for if you are going to an open-source system from a vendor-system and just saving so much money it's laughable to spend just $10 more a month on a firewall...

https://www.terraform.io/

This seems like an OpenSource version of CloudFormation...and it works on multiple clouds and on-premise? This is a far off topic, and would be something down the road...but might be an alternative to K8S. Still wouldn't mind doing K8S since I need to know more about containers, but this is amazing and I didn't know about it until today.

Thank you to @ThatYellow, our maybe-new-member who is my superstar colleague at Oracle for suggesting this :)
She has passed the AWS-SA-Associate as well.