To save the files of the Storage Bucket, we have chosen Amazon S3 for our model. It is highly scalable and any amount of objects can be stored in it.
Figure 1.5 Flowchart of inbox.
Figure 1.6 Storage bucket from manager’s point of view.
Figure 1.7 Flowchart of storage bucket.
A log will be maintained for storage and deletion of objects in QLDB safely. Figure 1.7 shows flowchart of storage bucket, and Figure 1.8 shows Manage Employees page from manager point of view.
Here, it shows the Manage Employees page of the manager in the organization. The managers can add new employees, update employees, and delete employees in the organization. Apart from that, he or she can also add and manage enterprises. Manager can search employee details just by entering the employee id of the employee in the search field. Manager has full authority over the employee, i.e., if he or she wishes to suspend any employee from accessing the application, then he or she can do so. Employees cannot access the Manage Employees page from their end as, at every step, manager’s credentials will be checked before giving allowance inside the system.
Figure 1.8 Manage employees page from manager point of view.
In our proposed model, we have used NoSQL databases because they are highly scalable and large volumes of data can be stored without having any specific architecture. Editing on these databases is quite fast and easy. If development is made using modern agile methods, then relations database is not the right option as it slows you down, but in NoSQL databases, the level of preparation is not needed making work faster. Moreover, cloud-based storage requires data to be spread across multiple servers. A highly scalable database is required for such production and NoSQL databases perfectly fit in the case. Figure 1.9 shows flowchart of employee database, and Figure 1.10 shows announcement page from manager point of view.
Here, it shows the Announcement page of the manager in the organization. Here, the manager can view, edit, add, and delete announcements. The manager can send announcements to the entire department by entering the department id of them.
In our proposed model, we have selected NoSQL databases for storing the announcements. As it has no predefined schema, storing important announcements or deleting them later can be done with great ease. We have chosen multi-level encryption. We will use DES and AES encryption to encrypt the database before pushing it to QLDB. DES is a symmetric encryption algorithm converting data into block ciphers. It uses key sizes of 64 bits.
Figure 1.9 Flowchart of employee database.
Figure 1.10 Announcement page from manager point of view.
AES encryption is the most robust security protocol against hacking. It uses higher key sizes such as 128, 192, and 256 bits of encryption. It is one of the safest open source security solutions widely used commercially for encrypted data storage.
First, we will encrypt the data using DES and generate a key and further encrypt it using AES providing a second level of encryption.
The encrypted files are stored in QLDB (Quantum Ledger Database), a ledger database holding all records. These files can be decrypted again and viewed in QLDB if needed. We have chosen QLDB for our proposed model as it is a NoSQL database, with some additional features. Figure 1.11 shows flowchart of creating announcement, and Figure 1.12 shows group access control modifier by manager.
In our architecture, a highly strict policy for least access privilege model is followed to ensure that no user gets access to resources more than he is supposed to. The Group Access Control Modifier thus provides that opportunity for the immediate senior managers assigned to the users to access their control privileges. This ensures that no information flows in and out of the system that is not asked to be retrieved by an authenticated user with necessary access. The Group Access Control Modifier is the GUI of a backend architecture with a JSON file containing the detailed Access Policy for specific users. Whenever the Access Policies are changed over in the GUI, the contemporary JSON file updates itself accordingly.
Figure 1.11 Flowchart of creating announcement.
Figure 1.12 Group access control modifier by manager.
1.5 Performance Analysis
1.5.1 Load Balancer
Load balancers are used to provide low latency to users especially at high usage periods and distribute the loads across multiple compute instances. Combining it with the autoscaling groups also enables our architecture to scale up and scale down as per requirements. In the absence of load balancers, higher traffic on instances would lead to higher packet loss and higher latency due to overloaded traffic, on a fixed number of compute instances. It would also lead to unbalanced load on web servers resulting in crashing of the servers. Due to the load-balanced architecture, a user may face a latency slightly above 1–5 ms, due to the load balancer operating at layer 7 and also since the instances are provisioned on demand automatically so it saves costs to a great extent.
1.5.2