1.3.2.9 QLDB
Amazon QLDB is a ledger database that provides an immutable, verifiable, transparent, and cryptographically transaction log centrally. It can be used to track and any application data change over time.
However, relational databases are not immutable and changes are hard to track and verify. Alternatively, blockchain frameworks can be used as a ledger but it adds complexity as an entire blockchain network needs to be set up and the nodes are required to validate each transaction before it can be added to the ledger.
With Amazon QLDB, effort of building your own ledger-like applications is eliminated. QLDB is immutable; it cannot be altered or deleted and can be easily verifiable if any unintended modifications are made. QLDB provides SQL-like API, a flexible document data model, and full support for transactions. With QLDB data can be replicated to other AWS services to support advanced analytical processing. QLDB is serverless so it is scalable according to my needs so I pay for what I use. In our proposed model, all the records of data and various other files are stored and maintained in QLDB.
1.3.2.10 NoSQL Database
In our proposed model, we have chosen NoSQL databases as it is perfect for our applications requiring flexibility, high-performance, scalability, and highly functional databases since it does not have any schema. The document type/JSON type files are stored in this database.
Sensitive data are secured using encryption algorithms mentioned in our architecture. The JSON files are being encrypted before getting stored inside the database.
1.3.2.11 Linux Instance and Networking
Instances widely provided by the public cloud provider services can be used or virtualized compute instances can be provisioned for hosting the application on private servers. In this project, we have used an AWS EC2 instance to set up the server side application on the instance for the client devices to communicate and transmit the messages. EC2 also provides additional security, and moreover, the compute capacity is easily resizable according to the demand.
Private servers can also be spun up if not going through with public cloud providers. The instances need to be spun up with updated hypervisors keeping scalability and durability in mind. Networking needs to be managed internally in that case and NAT gateways need to be set up to facilitate communication of the virtual instances through a public facing IP.
1.3.2.12 Virtual Network and Subnet Configuration
A specific virtual private network is required to be configured for the application spanning two or more availability zones for higher availability and application reliability. One public subnet and two private subnets need to be launched for each of the availability zone that we have accounted for. Private subnets would contain the user access and data, and the storage services and only the web application instances that are launched into the public subnet would be allowed to access. The application instances would be able to access the services provisioned into the private subnets through the private endpoints which are not exposed to the public internet. Thus, all the user/application data residing in the system cannot be accessed without prior authentication and authorization through the public endpoint.
1.4 Methodology
1.4.1 Firewall
In our proposed architecture, every incoming and outgoing data coming inside or going outside the cloud needs to be passed through the network firewall or VPC. Network firewall prevents several attacking problems like data exfiltration, insider attack, and many more. Here, we have created policies which are suitable for the organization. Every incoming and outgoing package can be blocked, filtered, and monitored. In addition, if any malicious activity is detected, then that can be blocked easily without affecting the entire system.
1.4.2 Malware Injection Prevention
The cloud or private server can receive data only from its client application. That data is always encrypted by the client application and never executes in the cloud without proper authentication, authorization, and validation of data. Inside the cloud, only specific actions can be done according to the privileges of the client which has been assigned by the organization. Apart from these, it can be prevented also from the VPC.
1.4.3 Man-in-the-Middle Prevention
Client application encrypts each and every data which it sends to the cloud. In addition, in the cloud after verifying, i.e., whether the client is trusted or not it will decrypt the data and perform the rest operations respectively. Since the data is encrypted by double layer encryption no middle man can tamper the data as a result MITM attack cannot be possible, i.e., no one can tamper the data in between the client and cloud.
1.4.4 Data at Transit and SSL
We have proposed to use TSL (Transport Layer Security), an updated and more secure version of SSL having advanced encryption algorithms integrated in it, giving extra security.
Nowadays, the encryption algorithms are all of single level encryption and hackers can easily hack the single level encryption so we propose to use multi-level encryption. First, we will encrypt the data using DES encryption technique on which we apply AES encryption technique giving a second level of encryption. Even by acquiring the data, decrypting such levels is a difficult task [14].
1.4.5 Data Encryption at Rest
To store big data files which have been uploaded by the client or organization in cloud for their use are stored, using several encryption algorithms like IDA (Information Dispersal Algorithm), SHA-512, and AES-256 (Advanced Encryption Standard) combinedly. This encrypted data is stored into Amazon S3 by splitting it into several parts. This encryption happens in server side, i.e., within the cloud. When any client or organization needing the data, it will undergo a decryption process, i.e., IDA is used to synchronize the encrypted data and it is reconverted into the initial data using AES-256 and SHA-512.
1.4.6 Centralized Ledger Database
After analysis of data, the JSON document is stored in QLDB. As the documents arrive, they will be stored in the journal one after another. If any document is changed, then a copy of it is maintained in a ledger called history. The rest remain in the current ledger. So, whatever data is in QLDB even if it gets deleted or updated is stored in the ledger and is easily viewable. For verifying data in QLDB, a SHA-256 secure hash file is generated from where the integrity of the data can be verified.
1.4.7 NoSQL Database
An encrypted JSON document will be stored in the hosted NoSQL database. The database would be encrypted at rest. While fetching data from the database, the files will be decrypted after checking the authorization details. After verifying the user to authorize or not, files can be updated from the database. In this way, data breaching can be avoided to a great extent.
1.4.8 Linux Instance and Server Side Installations
The server side application is developed using Python Django. Python version 3.x is recommended for development. Our application is developed using Python 3.8. The suggested required libraries