I initially didn't want to answer this question since the comments do a proper job of capturing the gist of it (i.e. discuss it with your SM/colleagues), but since I don't like neither of the currently existing answers, I'm just going to throw a wrench into the works here.
One of the answers basically says "How does the Scrum Master dare to do this", while the other answer says something like "You don't like it? Tough. Just suck it out and do it". Let's expand a bit on this.
First of all, as it happens with a lot of stuff, many things are situated on a spectrum. The existing answers touch on the ends of the spectrum. For example, the Scrum Guide says this about the development team:
They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;
This makes Barnaby's answer correct but somehow at one end of the spectrum: the Scrum Master has no right while the team has all the rights. Then we have Mike's answer where it's stated that:
The SM might well be responding to corporate accountability expectations "form above" which ... Must Be Obeyed.™
Which is also correct, but again, at the other end of the spectrum. This negates the characteristic of self-organization you have in Scrum, because it says that you must do whatever upper management tells you.
Let's think about the full spectrum now.
In between these two ends, you have a full range of possibilities. The Scrum Master (SM), since they are responsible for this whole Scrum thingy implementation, might have decided that this will help the team, but forgot that they are a servant leader and they should not take decisions without consulting with the team. Maybe the SM, in their own work, find this setup easier to handle but neglected to think what the impact will be on the rest of the team. Maybe the SM is a SM with just the name, a Project Manager in disguise, if you want, and they have the bad habit of doing what they want. And, yes, maybe the SM needs to present reports or what not to upper management and this setup helps them extract better data. And so on. You don't know the reasons until you discuss it together. Once you understand the reasons, only then you can decide what to do next. Stick with this setup, go back to the old one, find a third alternative, etc.
So discuss the reasons. You can do so at the retrospective, or you can just raise the point up with the SM when you have some time available for a chat.
With that being said, the SM also serves the organization, not just the development team. That means that if management decides to do something that badly impacts the development team, the SM should open up a discussion about it. In true Scrum implementations, upper management must interact and collaborate, not spit out orders to be followed. It's the SM's job to try to help the team while they are also responding to requests from above like reporting, status updates, etc. By discussing it with upper management, you can reach a conclusion that can satisfy both parties. But you have to discuss it.
If upper management doesn't care, they can impose stuff. That's why they are upper management. As a team you will then have to accept it, since you work there and are paid to do a job, and following upper management directions is part of your job. But if people in the team really want to use Scrum properly because they understand its benefits, but upper management decides to play by other rules, then they might get pissed off and decide that they go work for another company with the proper Agile values. And when people leave, it will have to be upper management this time, to accept the situation.
So once again: discuss it, find out the reasons, and figure out together what the best solution is given the situation.
EDIT: my comments on the SM explanation:
we are wasting too much time to update the jira board and we need it to be up to date for each daily.
Why are you wasting too much time to update the Jira board? I understand you are now working remotely, but when you were in the office weren't you using the Jira board? Was it fine then? What changed now?
So we need to add tasks on the board easily if we identify more work to be done and find the tasks easily.
Tasks are second class citizens compared to their parent user stories. You implement user stories during a sprint. Why is it so important to have tasks attached to stories and track those tasks? You can communicate about stories and their completion without tasks. I'm not necessarily suggesting you give up on tasks (it's your team, your policies, etc) but I've always found tasks to be an operational overhead and sometimes hide large stories (a large story with 2 tasks, instead of 2 stories).
we need to have a tool created with this in mind
One of the Agile values is "Individuals and interactions over processes and tools". You're jumping straight to tools here. This raises some red flags. You are trying to solve a problem by manually synchronizing boards and then you need to write a tool?!? Seems to me like the solution is worse than the problem you are trying to solve.
