Blogs

We help customers host applications on the cloud, this includes accounting systems including Tally, ERP software including SAP, and Navision. We host workloads only with leading public cloud providers which are Microsoft Azure, Amazon Web Services (AWS), and Google Cloud Platform (GCP).

We ensure that the solution is compliant from the licensing standpoint of both cloud providers (e.g., Microsoft) and business systems (e.g., Tally or NAV). We ensure that the system is secure and there’s no open access by implementing VPN and implementing backups.

All these services are fully managed. We perform regular monitoring of system performance, continuously evaluating the security posture, patching systems every month, and perform regular restore drills. And all this is proactive and there have been instances where we approached customers to reduce the server config (and hence reducing the cost) because of less load than expected. That is the beauty of Pay as You Go (PAYG).

I come across a question often from my team that our solution is costlier and also while discussing with customers that we are getting it at a much cheaper price than you are offering then why we should host with you. This bothered me and I decided to find out why our cost is higher than the so-called competition. I took help from one of the potential customers and spoke to the competition. And the following is what I found was making us costlier.

• Competition is using a remote access solution that is not compliant as per cloud or license provider licensing terms. You ask them about it, and they will have no answer. Test it out!
• They are not providing a VPN and the system is open from anywhere. They claim to have a firewall and antivirus but keeping your accounting system open to the whole world is a clear no-no from a business owner perspective.
• They have got into a contract with a third-party data center provider and will give you a server. Your contract is with them and not with the datacenter. There’s no direct control or visibility and shifting to another provider will be a nightmare.
• We enable you to host with major public cloud providers and the contract is between you and the cloud provider. You are the owner of the account. With the portal of Public Cloud, you can see your server and control it and even kick us out if we underperform and onboard another service provider. Think of the visibility and control you have. If I am a business owner, I cannot let my business systems under someone else’s control.
• We provide proactive managed services, so your systems are always running and secure with a data backup which is tested regularly.
• They give a fixed cost per user, our model is PAYG, so you can scale up or down easily.

I hope this gives us and our customers visibility of what you get when you host with us and what you lose when you host with a low-cost provider.

The Amazon Web Services (AWS) in terms of security follow a shared responsibility model. So, the security ‘of’ the cloud is on the shoulders of AWS, whereas you and your organization’s development team have to look after the security “in” the cloud. Hence, the protection of the infrastructure of the cloud, including hardware, software, and networking falls under the territory of AWS. All the other security objectives, including access to your AWS resources and the security of your application, is your responsibility. The following is an overview of four of the most common AWS security features you’ll need to keep your cloud secure.

1. S3 Security

S3 stands for Amazon’s Simple Storage Service, which is responsible for providing data storage with a high level of availability & durability. Just like all AWS services, the S3 by default denies access from most sources. Only the bucket and object owners (the AWS account owner) have read/write access by default. Hence, it becomes important to lock your S3 buckets so that no unauthorized users are able to view, upload, or delete your files. Contrary to other services, there are several ways of adding permissions to S3, like:

• Firstly, by giving IAM roles to your hand-picked users within your AWS account. They can be used to specify what the users are allowed to do, and how many of them have access to it?
• Usage of Bucket Policies to lock down a single bucket. There is an option of adding permissions to either the individual users or the entire AWS accounts. Bucket policies can be helpful if some files in your application are public and some are private.
• Use of Access Control Lists (ACL) to gain access for AWS accounts & not the individual users. These become very helpful when your company is in possession of & uses several AWS accounts or if any other organization needs access to your files.

2. Identity Access Management (IAM)

The IAM is a free-of-cost element of the AWS that allows you to control & manage- ‘what users have access to what services and resources. By default, access to resources is generally denied, so you will have to grant users permissions in IAM. Permissions are incredibly comminuted and allow you to specify the particular file or resources that a user can access, what the things are that they can do with the file and the work conditions that have to be present for the permissions to get activated – like, using a specific IP address to access AWS. Here are some best practices you should consider with IAM:

• Granting few privileges- Granting the users only the permissions they need to perform the tasks, and nothing more. This is very beneficial, as you can always grant more permissions, but you cannot obtain the databases that were deleted or removed because you made everyone an admin.
• Creation of groups- A group can be defined as a lump or collection of users that allows you to specify the various permissions for the concerned users. Because of this, tracking who has what permissions becomes very easy, plus you can add permissions to several users at once. For example, a group called Mismo AWS could be given full control over the AWS, while the other group, i.e., AWS Developers, in this case, may only be given access to Lambda and S3.
• Enable multi-factor authentication, or MFA, for all users. MFA means that, for a user to sign in, they will have to enter the passcode followed by an additional code that is sent to them through a secondary device, like a smartphone. This is very useful as, even if a user’s password is compromised, their account will not be accessible.

3. Cloud Trail

Your applications are not directly affected by CloudTrail, but it is essentially a tool used for tracking the activity of the users, compliance demonstration, and executing the security analysis. The review activity can also be searched through the logs created by CloudTrail. Overall, it is present by default, so you can view the logs as long as you have an AWS account. CloudTrail is very useful in determining whether your security configuration is sufficient or not? You can view the following from CloudTrail logs:

• The various updates to AWS services.
• The IP address source of the API calls.
• Which account created, deleted, or even modified the different AWS resources.

You can monitor and protect your organization’s digital assets with the built-in features of AWS. You have the power to determine which security features to employ and who has access to them. Your data gets stored securely on the cloud, & your organization’s unique security requirements are still under your control.

4. Security Groups

Elastic Cloud Compute also called EC2, instances are the actual servers on which the applications are run. Each server operates from a Virtual Private Cloud (VPC), a virtual network that you have control over. These VPCs have. There are many security groups in VPCs, which may or may not allow the entry of traffic.

In these security groups, you get to choose the traffic that can enter both in and out of your VPC. Security groups, however, are stateful, so if you allowed ‘in’ a request, its response is allowed ‘out’. By default, traffic is denied, so everything gets rejected if it is not specifically allowed ‘in’. It is quite common for all the traffic to be allowed for Outbound traffic (because you are the one who is sending it), but it is important to cut down on the type of inbound traffic that you allow. You can also specify the types of requests (like HTTP, SSH, etc.), the port range, & the source of traffic through these security groups.

For more of such blogs click here.