データ活用やDXがどんどん解る用語集
共通鍵暗号 / DES / AES(Advanced Encryption Standard)
「共通鍵暗号 / DES / AES(Advanced Encryption Standard)」
データ活用やDX成功に必要な考え方を、各種キーワードの解説で理解できる用語解説集です。
今回は、ITでの「安全安心」を支える技術である共通鍵暗号について、およびAESについて解説をします。
共通鍵暗号 / DES / AES(Advanced Encryption Standard)とは
共通鍵暗号とは、暗号化と復号化で共通の暗号鍵を用いる方式の暗号のことです。共通の秘密情報を共有することで、秘匿したい情報を互いに安全に送受信するために古代より用いられてきた技術のことを、あるいは近年登場した公開鍵暗号と区別して昔からある暗号技術のことをそのように呼びます。
AES(Advanced Encryption Standard)とは、アメリカ国立標準技術研究所(NIST)が公募を経て2001年に標準化した、世界で広く利用されている共通鍵暗号アルゴリズムです。
目次
暗号の例、および暗号解読の例
「共通鍵暗号」は聞いたことがない言葉かもしれませんが、世間で単に「暗号」と言われているものは、ほとんど共通鍵暗号のことです。単に「暗号」と呼ばないのは、近年登場した「公開鍵暗号」と区別して、そうではない従来からの暗号として「共通鍵暗号」と呼ぶようになったためです。では「暗号」とは何で、どういうものでしょうか。
古代の暗号の例:シーザー暗号
暗号技術はIT時代になるよりもはるか前、古代より利用されてきました。軍事や外交において機密情報の漏洩を防ぐために、指令書などが敵の手に渡っても「何が書いてあるのかわからない」形でメッセージを届ける手段として利用されてきました。
古代に利用されていた暗号として有名なものに「シーザー暗号」があります。例えば、以下のような暗号文があったとします、
ZWPWOLEZAN EO CKKZ
何が書いてあるのかよくわかりませんね。しかしこの謎アルファベット列を「アルファベット順に4文字ずらす」操作をしてみましょう。例えば「AならばE」「ZならD」というようにです。
DATASPIDER IS GOOD
一見、意味の解らないことが書いているように見えたものが、一気に読めるようになりました。実際のシーザー(古代ローマのカエサル)は、実際にはもっと複雑な暗号を利用していたのではないかという話もあるようですが、一般的にこのような方式の暗号は「シーザー暗号」と呼ばれます。
換字式暗号(かえじしきあんごう)
さてシーザー暗号、整理するとこのようになります。
- 暗号化アルゴリズム:アルファベットを所定の文字数ずらして変える
- 暗号鍵:4文字ずらす
暗号文を解読して元の平文に戻すためには、「どのようなアルゴリズムが用いられているか」を知っている必要があり、さらには「どのようなパラメータ(暗号鍵)を用いて暗号化されているか」(シーザー暗号なら「何文字ずらし」なのか)も知っている必要があります。
またシーザー暗号は暗号化アルゴリズムとしてさらに一般化することができます。具体的には、「ある文字を他の文字に置き換える」方式のとても単純な例とみなすことができ、文字を置き換える方式の暗号化アルゴリズム一般のことを「換字式暗号(かえじしきあんごう)」と呼ぶことがあります。
例えば、以下はシーザー暗号をより一般化した換字式暗号の例です。
- 暗号化アルゴリズム:平文の文字を、所定の手順で他の文字に置き換えて暗号文にする
- 暗号鍵:アルファベットの文書なら「アルファベット26文字」→「アルファベット26文字」の置換表など
換字式暗号は一文字ごとに置き換える必要性はないので、さらに強度を高くすることもできます。
- 暗号化アルゴリズム:任意の「アルファベット二文字の並び」を、所定の手順で「アルファベット二文字の並び」に置き換える
- 暗号鍵:「アルファベット26文字×26文字」→「アルファベット26文字×26文字」の置換表
暗号解読の例(頻度分析)
では、このようにして暗号化すれば解読されず安全なのかというとそんなことはありません。単純な換字式暗号なら簡単に解読されてしまいますし、国家レベルで整備された非常に複雑な換字式暗号であっても(ナチスドイツのエニグマ暗号や、日本海軍のD暗号など)解読されてしまうことがあります。
では次に「単純な換字式暗号」ならあっさり解読できてしまうことを紹介しましょう。
例えば、英語で書かれた平文が「アルファベット一文字ごとに別の文字に置き換える換字式暗号」で暗号化されているとします。英語の文章ではアルファベットの出現頻度に偏りがあることが解っています。例えば「Q」が出現することは稀で、「E」は多く出現し、「T」「A」「O」「N」なども多いことが解っています。ならば、
- 暗号文での文字の出現頻度をカウントする
- 一番多い文字はおそらく「E」である
- その次に多い文字も、おそらく「TAON」など出現頻度の多いもののどれかである
そのようにして類推して読める組み合わせを見つけると、案外とあっさりと解読されてしまいます。コナンドイルの書いた「シャーロックホームズ」の作品「踊る人形」に、「事件現場に残された、踊っている人形の落書き」が実は暗号文であることに気が付いて、まさにこのようなやり方で暗号を解読する話があります。以下、青空文庫からの引用です。
⇒ 三上於菟吉訳 大久保ゆう改訳 踊る人形 THE ADVENTURE OF THE DANCING MEN アーサー・コナン・ドイル Arthur Conan Doyle(青空文庫)
- つまり、両手を挙げたこの人形
は、アルファベットのEであると。ご存じの通り、Eというのは英語のアルファベットで最もよく使われ、その頻度は、どんな短文にもたくさん見つかるほどです。最初の伝言にある十五の文字のうち、同じものが四つ、さすればこれをEとするのが合理的です。
そして一文字が確定できると、このようにして他のアルファベットも類推できてしまいます。
- もし私の読み通り、これがあのご婦人と昔親密にしていた者からのメッセージだとすれば、この両端にEがあり、中に三文字ある組み合わせは、ELSIE、『エルシィ』という名前をまさに指しているのかもしれぬ。よく調べてみれば、この組み合わせが三度、伝言の末尾に現れている。とすれば、これはエルシィ宛の文章に相違ない。こうしてL、S、Iがわかった。しかし何を伝えようとしているのか? たった四文字だけが、エルシィという名の前に描かれていて、末尾はE。きっとCOME、『来い』という意味に相違ない。他にも末尾がEの四文字を考えたが、この状況に見合うものは他にない。そうしてさらにC、O、Mがものになったので、再び最初の伝言に挑んでみた。
この作品は1903年に書かれています。当時は大英帝国の全盛期、コンピュータなどはまだ全然ない時代。それでもすでに、暗号と暗号解読についてはかなり研究が進められており、推理小説の作家にすら「単純な換字式暗号は、文字の出現頻度から解読できる程度のものである」ことが知られていたことが解ります。
暗号解読の例(総当たり)
また暗号は「力業」で解読することもできます。例えばシーザー暗号、ずらせる文字数のバリエーションは「1文字から25文字」しかありません。ならば、「25パターンを全部試す」ことで、その中から読める文がでてくるのでそれで解読できてしまいます。このように暗号は、暗号鍵の取りうるパターンを全部調べることで、強引に解読できます。
特に今はコンピュータがありますから、このような「総当たり」での暗号解読は行いやすくなりました。暗号鍵が16bit分しかないなら65536通りを全部試すだけなのでほとんどの場合に解読できます。32bitでも4,294,967,295(42億)通りなので、毎秒1万通りで総当たりできれば(5GHzのCPUなら50万クロック以内で一回計算できれば)、4日で全て調べつくせることになります。しかも今では猛烈に並列計算ができるGPUも暗号解読に利用できるようになった時代なので、総当たりでの攻撃はどんどん容易になっています。
公開された暗号化アルゴリズム
さて、再度話を整理しましょう。共通鍵暗号は、平文を暗号化するときに使う暗号鍵と、暗号文を平文に戻すときに使う鍵(ないしは秘密の情報)が同じである暗号化アルゴリズムのことでした。
- 平文 →(暗号化アルゴリズム+暗号鍵)→暗号文
- 暗号文→(暗号化アルゴリズム+暗号鍵)→平文
たとえば、「シーザー暗号」で「4文字ずらす」とか、「アルファベット一文字ごとの換字式暗号」で「この人形はEに対応させる」などです。
そして「その暗号アルゴリズムが安全である」とは、「暗号鍵を知らない人が暗号文だけを知っていても平文を推測できない」ことになります。例えば、「単純な換字式暗号」は文字の出現頻度の分析で解読されてしまうため、「安全ではない暗号化アルゴリズム」とみなせる例でした。
つまり、データを暗号化して「安全安心」に相手に届けるためには、
- 「安全な暗号化アルゴリズム」を使うこと
- ◦解読できる弱点が存在せず、総当たりでの解読もできないこと
- 送信者と受信者の間で、漏洩などがないように安全に「暗号鍵」(秘密情報)を共有すること
が必要であることがわかります。このうち、暗号鍵(パスワードなど)を注意して取り扱うことは、すでに皆さんも行っていることだと思います。あとは「安全な暗号化アルゴリズム」を使うようにすればよいことになります。このような状況で検討すべき選択肢に、世界中で広く使われている「AES(Advanced Encryption Standard)」があります。
AESは事実上「世界標準の共通鍵暗号」と呼べる技術です。また、「暗号の実装に関することが詳細まで全て公開されている」暗号アルゴリズムであることも特徴です。もしかすると「暗号技術の全て公開されている」よりも「どういう仕組みで暗号化するのかも秘密になっている」方が安全なのではないか、と思うかもしれませんが、実はそうではないのです。
どうして「公開された暗号化アルゴリズム」を用いるのか
歴史の長い間、「暗号化アルゴリズム自体も秘密とする」ことで安全性を高めることが主流でした。特に軍事や外交での暗号利用が主だった時代にはそれが当たり前だったのですが、ITの普及が進んだ今では「公開されている暗号化アルゴリズム」が用いられることが多くなっています。
暗号技術は今では、外交や軍事などで敵に解読されないことを主とした利用ではなく、民間の経済活動においてデータを安全安心に届ける手段として利用されるようになりました。国家機密を守る極秘の手段のような用途ではなく、民間の経済活動を支える基盤として、「誰もが使える安全安心な暗号技術」が重要な時代になってきました。
- かつての暗号技術
- ◦戦争や外交で用いられ、国家機密やスパイが暗躍するような世界で用いられる極字の技術
- 現在の暗号技術
- ◦民間でのIT利活用における「データを安全安心に届ける」手段として、社会活動や経済活動の基盤として活躍が期待されるようになった技術
暗号に関連する研究が進み、コンピュータの計算能力の向上も著しいために安全性を保ちにくくなっている事情もあります。公開技術とすることで、世界中の暗号研究者の知見を持ち寄った方が高度な技術が実現できる可能性が高まります。さらにはその暗号化アルゴリズムに弱点がないのかについても、公開された技術ならば全世界の暗号研究者により弱点がないか日々研究を続けられ、それでも致命的な弱点が見つかっていないこと自体が「安全性が保たれているのではないか」と考える材料になるはずです。
もちろん、誰か(あるいはどこかの悪い国)が、「弱点に気が付いたが内緒にしている」リスクや、そもそも最初から「秘密の弱点」が埋め込まれており、その秘密を知っている人は解読し放題なものを使わされているリスクもゼロではありません(実際そのような「陰謀論」もあります)、しかし今では公開された暗号化アルゴリズムを利用されることが多くなっています。
DES(Data Encryption Standard)暗号
このような「公開され全世界で利用される暗号化アルゴリズム」の最初のものが、1976年にアメリカ政府の関係機関である「国立標準局 (NBS)」により標準化された「DES(Data Encryption Standard)」です。
1972年:標準暗号技術の必要性がレポートされる
コンピュータの利用そのものがまだ黎明期だった1972年に「コンピュータキュリティの必要性」が米政府でレポートされたことに始まります。
コンピュータが世の中に浸透して活躍するのはまだまだこれからの時期でしたが、今後、世の中でコンピュータが活躍する時代が来るにあたり、コンピュータセキュリティが安全安心の基礎としてきちんと確保されることが重要であるという研究結果が政府に提出されます。そこから社会の「安全安心」の基盤として標準暗号技術を作ることになります。
アポロ計画による月面着陸は1969年、ベトナム戦争の終結は1975年4月30日というくらいの昔、米ソ冷戦のさなかでのことでした。それくらいの昔においてすでに「安全安心の標準技術を社会の基盤とする必要性」が認識されていました。
1973年:要求仕様が公開されて公募されるも、すべて不採用
国立標準局 (NBS) がアメリカ合衆国の公式連邦情報処理標準 (FIPS) として採用する暗号が満たすべき要件を定め、それを満たす暗号技術が公募されます。しかし、要件を満たす技術の応募がなく全て不採用となります。
1974年:二度目の公募がなされる、IBMの案が採用される
翌年、再度公募がなされ、IBMが開発した「Lucifer暗号」が採用されます。そして、それを基にしてDESが作られます(後述しますが、IBMの案をそのまま採用しなかったことが後に禍根を残すことになります)。
1976年:DESが生まれる
DESが生まれます。DESはData Encryption Standardの略であり、訳すと「データ暗号化標準」と、そのままの名前になります。鍵長56ビットのブロック暗号。高度な暗号化技術が民間でもみんなで使えるようになりました。
XOR演算、ビットシフト、テーブル参照など実装が容易な演算のみで構成されていて、処理が高速であり、ハードウェア化も容易なところも特徴でした。
DES暗号に関する疑惑と驚きの結末(安全安心の基盤を作るにあたっての重大な教訓)
DESはIBMが公募に対して提案した技術そのものが採用されませんでした。IBMの案が修正されたものがDESになっており、しかもその過程でNSA(アメリカの情報機関:有名なスノーデン氏も所属していた組織)が関与していたことが明らかになり、さらには以下のように具体的に疑惑を招く事象もありました。
- 56ビットの鍵長は短すぎるのではないか?とIBMは考えたが、NSAが56ビットで十分で、その方が民間での利便性が高いとIBMを説得して鍵長を減らさせていた
- 暗号の設計に「設計理由が謎の部分」があった(S-BOX)。S-BOXはIBMの最初の提案には含まれておらず、NSAの関与後に出現しており、その設計理由が不明だった
そのため、DESにはNSAだけが簡単に暗号を解読できるバックドアが仕込まれているのではないかという疑惑(ないしは陰謀論)が広まってしまいます。
この事件は、広く世間の皆様に「安全安心である」と信頼をいただくものを作るためには、「何をしないといけないか」「何をしてはいけないか」を考えさせる重大な教訓だと思います。
DESを基盤に暗号研究が飛躍的に進む(DESが安全安心の標準になる)
DESができるまで具体的な暗号技術の研究や利用は、軍事や諜報分野の取り組みにほとんど限られており、特殊な分野でした。
オープンな技術で詳細がすべて公開され、自由に利用できるDESが登場したことで、暗号をめぐる技術開発や利用が盛んになります。一般の大学でもDESを基準にした暗号研究が進むことになります。標準技術となることにより、暗号技術の研究インフラそのものとなり、「世界中の暗号技術研究者により検証されても問題が見つかっていないなら、おそらくそれなりに安全である」とも思えるようになってきます。
DESの疑惑の設計の真意、1990年になって判明
1990年になり、DESの「謎の設計」の真意がようやく判明します。
1990年に「差分攻撃法」という共通鍵暗号で広く利用できる一般的攻撃方法が論文発表され、差分攻撃により多数の暗号アルゴリズムが深刻なダメージを受けて安全に使えなくなる事件が起こりました。当時は日本が繁栄を謳歌していたバブル時代でしたが、技術でも世界をリードしているつもりだった日本から提案されていた国産暗号技術(NTTの研究所が開発したFEALなど)の多くも残念なことになりました。
多くの暗号技術が差分攻撃に敗れる中、古参の暗号技術であるはずのDESは差分攻撃を受けても致命傷は負いませんでした。実は、IBMは1974年に差分攻撃法を発見していました、しかし国家機密として非公開となっていただけでした。
DESの疑惑「S-BOXの謎の設計」は、「差分攻撃への耐性を持たせる設計」でした。世の中の皆さんに安全な暗号技術を使ってもらいたい、そう思ってなされていた設計だったのです。そうだったのに、それが結果的に陰謀論を生みDESへの不信を招いていました。安全安心はどうあるべきか、考えさせられる結末です。
AES(Advanced Encryption Standard)とは
AES(Advanced Encryption Standard)はDESが能力不足になったことを受けて開発された、現時点において世界で広く使われている共通鍵暗号の暗号化アルゴリズムです。
DESの56ビット鍵長では総当たり攻撃に対して強度不足になり、90年代でも既に「総当たりでのDES解読に成功する例」が出てきていました。さらには、差分攻撃や線形攻撃により防御力が削られた状況もありました。
そこで、DESによる暗号化処理を三回施すことで実質112ビット相当まで暗号強度を高めた「トリプルDES(3DES)」によりDESを延命させつつ、その後継技術として全世界から公募されて採用された暗号化アルゴリズムが「AES」です。
DESの大きな問題を解消
- 56ビットでは強度不足になった点や、差分攻撃や線形攻撃など新しい攻撃への対応
- DESを作る経緯での不透明さが招いた疑惑の払拭
すべて透明でオープン
アメリカ国立標準技術研究所(NIST)の主導による公募ですが、「公募から決定までのすべてのプロセスをオープンで透明なもの」とし、疑惑などが生じないようにしました。
技術自体もすべて公開され、C++とJavaによるリファレンス実装のソースコードがオープンソースで公開され、「そのように実装した理由」「選定過程」などもすべて公開されています。
欧州からの提案が採用される
世界各国からの応募の中から、欧州ベルギーのルーヴェン・カトリック大学の研究者が作ったRijndael (ラインダール)が採用され(2000年10月)、2001年3月に正式にAESとして公表されます。つまりAESは、アメリカで作られたものではありません。
暗号強度
鍵長を128ビット、192ビット、256ビットを選ぶことができます。ブロック長(暗号化する単位)は128ビット。Rijndaelそのものは鍵長やブロック長は可変長でもっと自由なビット超で利用できますが、AESの公募基準により上記のとおり固定されたものがAESとなりました。
世界中の誰でも無料で自由に利用できる
権利関係などにも問題がなく、技術自体もオープンなので、世界中の誰でも無料で自由に利用できます。
実装や処理も効率的にできる
他方式に対して、実装や処理が効率的にできることも評価されての採用でした。
利用者の「安全性の説明」が簡単
このような経緯で作られ利用されている暗号アルゴリズムであるため、システムの安全性について説明を求められる場合にも「世界標準のAESを使っています」で済みます。
現時点(執筆時点)では攻撃に対して無傷
AESに弱点がないかは日々調べられており、暗号を攻撃する手法自体についても新たな攻撃方法が見つけられたりもしていますが、(攻撃の足掛かりとなる弱点が見つかっていることはあるものの)今のところ暗号強度が下がるような問題点は見つかっていないようです。
あるいは、AESができてから20年以上、世界中の研究者研究機関による検証を経ても問題点が見つかっていないこと自体が、AESを「安全安心」と考える材料であるとみなされています。
思ったよりも重い「実績のある選択肢」の意義
このような経緯があり、さらには各国政府も含めて世界中で利用されている実績もあることから、AESはデータを暗号化する技術として採用しやすい状況があります。
相応の安全性を備えていると考えられるだけではなく、AESに対応したソフトウェアが世の中に広く普及しているなどエコシステムが整備されていることも長所であり、「世界標準のAESを採用しています」と、採用理由を説明しやすいことも利点です。
もう一つの例で「安全安心」を確保する難しさを考えてみる
「標準的な技術となっている」「関係することが整備済みである」ことは、技術に関する様々なリスクをどうするかについて、あるいは実際にITシステムとして運用する際に発生する多くの問題をどうするかについて、自分たち自身で対処しなければいけないことを大きく減らします。このことは予想外なくらいに重みがあります。このことについて、よりイメージしやすい「安全安心に関連するもう一つの例」により考えてみましょう。
AESはファイルなどの「データのひとかたまり」を暗号化する技術(ブロック暗号)ですが、それだけでデータを安全安心に利用できる環境の要素技術が全て揃うわけではありません。例えば、本店の業務システムから支店の業務システムにデータを送付する、あるいはA社からB社にデータを送付するような場合を考えると、データの転送が安全安確実心に行える環境も必要になります。
「ファイルを転送するくらいのことだから簡単に作れるのでは」と思う人も多そうですが、通信経路上での回線障害やデータ化けの可能性、関係するシステムが障害を起こして処理の途中で停止する可能性なども考えると、「送れば多分届くと思う」程度では済まない用途なら(業務でのIT利用は大半そうであるはず)、あっという間に簡単には実現できない要求になってきます。
- 転送中に通信エラーでファイル(データ)が壊れることは実際みられる現象
- ◦「ファイルを送信してほしい」と頼むだけで、ファイルが壊れたり内容が化けたりせず転送先に届く必要がある。
- ◦転送中にどのような問題が発生しうるか理解し、必要なリカバリー機能やモニタリング機能などを整備する必要がある
- 転送路でのセキュリティ懸念
- ◦適切な暗号化がなされ、無用な一時データが残らないなど、セキュリティの認証制度をクリアできる水準を実現しなければいけないことがある
- 多種多様な環境への対応
- ◦メインフレーム、Linux、各種UNIX、Windows、クラウドなど様々な環境への対応が必要になることがある
- ◦特に、クラウドとメインフレームのような大幅に異なる環境間でもスムーズに利用できる転送処理は実装容易ではないことが多い
- ◦さらにはOSなどのバージョンアップ対応や、新しいクラウドサービスなど新環境への対応も継続的に必要になることがある
- 実際の運用を踏まえた運用環境や、周辺エコシステムの整備
- ◦転送機能だけではなく、ログ機能やユーザ権限やその管理機能など、周辺の機能も整備されている必要がある(が忘れられがち)
- ◦運用上発生しがちな難しい状況への対処能力、例えば回線トラブルやシステム障害発生時に「どのファイルまできちんと届いたのか」「送った送っていない、どちらの責任かで揉めている」のような状況で実用的に必要なログや機能は何であるか理解し、実装する必要がある
- これらを踏まえて「安全安心に作られていること」を納得してもらう手間
- ◦お客さんに「そのシステムが大丈夫であること」を説明し保障する必要があるが容易ではない。リリースの度に毎回テストを行って確認することだけでも、工数と時間がかかってしまう
一見簡単に思える「ファイルを転送するだけ」でさえ、業務を任せられる水準でしっかり利用できる「ファイル連携基盤」の整備であると考えるとすぐにこのようなことになってしまいます。ではどうしたら良いでしょうか。同じように「標準的な技術となっている」「関係することが整備済みである」プロダクトを採用すること現実的であるはずです。
弊社のファイル連携ミドルウェア「HULFT(ハルフト)」は、上記のような多数の問題を一気に無くせる既存の定番プロダクトの例です。銀行の基幹システムなど高度な「安全安心」が求められる分野で、基幹システム同士を連携させる手段として長年にわたって利用されているため、日本国内では「基盤としてHULFTを使っています」だけでお客さんへの説明も済むこともあります。
実績あるプロダクトを理解して採用する
暗号というと、秘密にして隠すことで安全安心を確保しているような印象を持っていた人もいるかもしれませんが、今や「その分野での標準的に利用されている公開技術」を採用し、その技術が公開されることで積み上げてきた実績や信頼をうまく利用する考え方になってきているという話でした。
むろん、AESに知られていない弱点があって人知れず悪用されていた場合など、「みんなが使っている技術」を採用するリスクもあることは理解しておく必要がありますが、独自技術の採用にもリスクがあって、その対処は容易ではないことも併せて考える必要があります。
- 技術選択
- ◦標準技術AESを安全安心の基盤として採用する
- その理由を説明できることが重要
- ◦「どうしてAESの採用が妥当なのか」を説明できるようする
- 実際に安全安心を実現するには
- ◦暗号化に用いるパスワードの運用が安全安心を実現する鍵であるので、細心の注意を払う
いわば「作る」のではなく、「すでにあるものをうまく使う」考え方です。多くの場合にはより安全安心になることが見込まれ、作らなければいけないことは減り、自分たちで担わなければいけないリスクや厄介ごとも減るはずです。なぜその技術を選定したのかの説明も簡単に済むことが多いはずです。
ITエンジニアにとって、このようなことは大変ありがたいはずです。「どうして採用すべきなのか」を適切に利用できるようになっていれば、AES(やHULFT)はITシステムの提案や実現に際して、有効で優位をもたらすカードとして使えるのではないかと思います。
関係するキーワード(さらに理解するために)
- MFT
- -技術的に難しいこともある「ファイル連携」を実現する手段が既に存在します。MFTを使えば、高度に完成されたファイル連携基盤がスムーズに出来上がります。
- ファイル連携
- -どうして「ファイル転送」を連携手段として用いるのだろう?と思われたらこちらもご覧ください。
- EAI
- -様々なシステムをデータ連携できることが、いかに重要であり、深い意義があるかについて説明しています。
- iPaaS
- -様々なクラウドを外部のシステムやデータと、GUI上での操作だけで「つなぐ」クラウドサービスのことをiPaaSと呼びます。
HULFTに興味を持たれましたら
国産MFT製品の最高峰にしてデファクトスタンダード「HULFT(ハルフト)」を是非お試しください。ITシステムに対する厳しい要求のある金融機関で基盤製品として「安全安心」のニーズにこたえてきたなど圧倒的な実績があります。
MFTのデファクトスタンダード「HULFT(ハルフト)」
メインフレームからLinuxやWindowsまで、新旧の利用環境への対応はもちろん、クラウドサービス(Amazon S3など主要クラウドとの転送に対応)とのファイル連携や、コンテナ技術への対応など、クラウドネイティブの時代でも活躍できる機能強化にも取り組んでいます。
ファイル転送の前後で必然的に生じる、様々な処理を効率的に実現できる機能も備えています。メインフレームとクラウドを、双方に詳しいエンジニアを要さずに縦横無尽に連携できるなど、新旧のIT技術を組み合わせて活用する手段としても活用いただいています。
HULFTは長年の実績があり昔からあるプロダクトですが、AES暗号化に対応するなど現在における標準的な技術やIT環境への対応も進められています。他にも、Amazon S3などのオブジェクトストレージとの転送にも対応し、さらにはコンテナ環境での利用にも対応し、マイクロサービスによるクラウドネイティブなアーキテクチャで自然に利用できるようになっているなど、時代の変化に合わせたアップデートも続けられています。
用語集 コラム一覧
英数字・記号
- 2025年の崖
- 5G
- AI
- API【詳細版】
- API基盤・APIマネジメント【詳細版】
- BCP
- BI
- BPR
- CCPA(カリフォルニア州消費者プライバシー法)【詳細版】
- Chain-of-Thoughtプロンプティング【詳細版】
- ChatGPT(Chat Generative Pre-trained Transformer)【詳細版】
- CRM
- CX
- D2C
- DBaaS
- DevOps
- DWH【詳細版】
- DX認定
- DX銘柄
- DXレポート
- EAI【詳細版】
- EDI
- EDINET【詳細版】
- ERP
- ETL【詳細版】
- Excel連携【詳細版】
- Few-shotプロンプティング / Few-shot Learning【詳細版】
- FIPS140【詳細版】
- FTP
- GDPR(EU一般データ保護規則)【詳細版】
- Generated Knowledgeプロンプティング(知識生成プロンプティング)【詳細版】
- GIGAスクール構想
- GUI
- IaaS【詳細版】
- IoT
- iPaaS【詳細版】
- MaaS
- MDM
- MFT(Managed File Transfer)【詳細版】
- MJ+(行政事務標準文字)【詳細版】
- NFT
- NoSQL【詳細版】
- OCR
- PaaS【詳細版】
- PCI DSS【詳細版】
- PoC
- REST API(Representational State Transfer API)【詳細版】
- RFID
- RPA
- SaaS(Software as a Service)【詳細版】
- SaaS連携【詳細版】
- SDGs
- Self-translateプロンプティング /「英語で考えてから日本語で答えてください」【詳細版】
- SFA
- SOC(System and Organization Controls)【詳細版】
- Society 5.0
- STEM教育
- The Flipped Interaction Pattern(解らないことがあったら聞いてください)【詳細版】
- UI
- UX
- VUCA
- Web3
- XaaS(SaaS、PaaS、IaaSなど)【詳細版】
- XML
- ZStandard(可逆データ圧縮アルゴリズム)【詳細版】
あ行
か行
- カーボンニュートラル
- 仮想化
- ガバメントクラウド【詳細版】
- 可用性
- 完全性
- 機械学習【詳細版】
- 基幹システム
- 機密性
- キャッシュレス決済
- 共通鍵暗号 / DES / AES(Advanced Encryption Standard)【詳細版】
- 業務自動化
- クラウド
- クラウド移行
- クラウドネイティブ【詳細版】
- クラウドファースト
- クラウド連携【詳細版】
- 検索拡張生成(RAG:Retrieval Augmented Generation)【詳細版】
- コンテキスト内学習(ICL: In-Context Learning)【詳細版】
- コンテナ【詳細版】
- コンテナオーケストレーション【詳細版】
さ行
- サーバレス(FaaS)【詳細版】
- サイロ化【詳細版】
- サブスクリプション
- サプライチェーンマネジメント
- シンギュラリティ
- シングルサインオン(SSO:Single Sign On)【詳細版】
- スケーラブル(スケールアップ/スケールダウン)【詳細版】
- スケールアウト
- スケールイン
- スマートシティ
- スマートファクトリー
- スモールスタート(small start)【詳細版】
- 生成AI(Generative AI)【詳細版】
- セルフサービスBI(ITのセルフサービス化)【詳細版】
- 疎結合【詳細版】
た行
- 大規模言語モデル(LLM:Large Language Model)【詳細版】
- ディープラーニング
- データ移行
- データカタログ
- データ活用
- データガバナンス
- データ管理
- データサイエンティスト
- データドリブン
- データ分析
- データベース
- データマート
- データマイニング
- データモデリング
- データリネージ
- データレイク【詳細版】
- データ連携 / データ連携基盤【詳細版】
- デジタイゼーション
- デジタライゼーション
- デジタルツイン
- デジタルディスラプション
- デジタルトランスフォーメーション
- デッドロック/ deadlock【詳細版】
- テレワーク
- 転移学習(transfer learning)【詳細版】
- 電子決済
- 電子署名【詳細版】
な行
は行
- ハイブリッドクラウド
- バッチ処理
- 非構造化データ
- ビッグデータ
- ファイル連携【詳細版】
- ファインチューニング【詳細版】
- プライベートクラウド
- ブロックチェーン
- プロンプトテンプレート【詳細版】
- ベクトル化 / エンベディング(Embedding)【詳細版】
- ベクトルデータベース(Vector database)【詳細版】
ま行
や行
ら行
- リープフロッグ現象(leapfrogging)【詳細版】
- 量子コンピュータ
- ルート最適化ソリューション
- レガシーシステム / レガシー連携【詳細版】
- ローコード開発(Low-code development)【詳細版】
- ロールプレイプロンプティング / Role-Play Prompting【詳細版】
わ行
おすすめコンテンツ
まずは無料で「つなぐ」をご体験ください
DataSpider Servistaのデータ連携を、まずはお確かめください。30日間無料でお試しいただけます。
DataSpider Servistaの「つなぐ」を体験できる製品紹介・オンラインセミナーを開催しています。
