it shows the inbox page of the manager in the organization from where he or she can send mail within the organization. Just by entering the client id of the employee, the mail will be received to the employee’s inbox. It can contain any number of documents by attaching it with the storage bucket. Here, past mails or drafted mails can be edited, modified, and sent. If the manager wants to send the mail to the entire department, then it can also be done by tagging the entire department. All those details, i.e., data in transit and data in rest will be encrypted and safely stored in cloud such that no third party applications cannot take the data without the owners concerned [15]. Employees have the access to view the mails sent to them and reply to them. Figure 1.5 shows flowchart of inbox, and Figure 1.6 shows storage bucket from manager’s point of view.
Here it shows the Storage Bucket page of the manager in the organization. Manager can upload any data in the storage bucket and can share it easily within the organization. Employees can do their work by making a copy of the data and can submit it when they finish. When a manager needs to search any files he or she just needs to search by the file name or client id in the search field. Apart from that, the manager can also sort the table according to his or her own preference. Managers have the permission to view, create and delete the files of all the employees. Employees can only access the files or documents only for those they have been eligible for.
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.
