最近よく聞く「データセンター」ってなに？ | IIJ Engineers Blog
IIJ 技術担当部長 最近はインターネットの技術を紹介するのがお仕事です。元々プログラマ、サーバ・データセンター・ネットワーク・セキュリティ・モバイルといろいろやってきました。 最近ニュースなどで「データセンター」がよく取上げられます。実は、この記事を書いている私自身も、TV番組に出演してデータセンターの解説をしていました。 千葉・印西市に世界が注目 データセンター集結の理由は【Bizスクエア】 2024年3月28日放送(TBS) 池上彰のニュースそうだったのか!! 2024年5月4日放送【1時間9分あたり～】 (テレビ朝日/TVer) この番組で取材を受けたのは「IIJ白井データセンターキャンパス」(千葉県白井市※)です。 ※印西市・白井市にまたがる千葉ニュータウンの一角に立地 番組中でもいろいろご説明しているのですが、この記事では基本に立ち戻って「そもそもデータセンターって何なの？」
「認証」を整理する | IIJ Engineers Blog
英語の「Authentication」を整理する ここからは先ほどの分類で言うところの「ユーザ認証」としての「認証」、つまり英語の「Authentication」に該当する「認証」について、さらに整理を進めていきます。 先ほど、「ユーザ認証」を「システムを利用しようとしているユーザを、システムに登録済みのユーザかどうか識別し、ユーザが主張する身元を検証するプロセス」と説明しました。「ユーザの識別」と「身元の検証」はユーザ認証に欠かせませんが、実際は他にも「ユーザの有効／無効状態の確認」や「検証に成功した場合の身元の保証（アクセストークンの発行等）」などの処理も一般的にユーザ認証のプロセスには含まれます。 ここで冒頭の「○○認証」を振り返りましょう。パスワード認証、SMS認証、指紋認証、顔認証は実はここで言うユーザ認証には該当せず、ユーザ認証中の一処理である「身元の検証」を担っていることがお
HTTPSレコードがRFCになりました | IIJ Engineers Blog
RFC9460が出ました 昨年、このエンジニアブログでHTTPSレコードについてとりあげました。これを書いたときはHTTPSレコードはまだインターネットドラフトだったのですが、2023年11月、ついにRFC9460として標準化されました。 RFCにはなったけど日本語の詳しい記事はまだ少ないし需要あるかなーと思って改めて解説を書きはじめたんですが、だらだらとクソ長くなって書いた本人が読んでも眠くて退屈な内容になってしまいました。ので、書いたものはばっさり捨てました。 そういえばいまから3年前、DNS Summer Day 2021で発表したプレゼン資料がありました。これをRFCになった現在の内容にあわせてアップデートしたほうがてっとりばやいしわかりやすそうです。 ということで、加筆修正した資料を置いておきます。DNS屋さんはとりあえず全部読んでおいてください。Web屋さんは前半だけ理解してお
Linux カーネルをバイパスして TCP 通信を 10 倍速くする | IIJ Engineers Blog
【IIJ 2023 TECHアドベントカレンダー 12/16の記事です】 この記事について 背景：TCP はコンピュータネットワークの通信において広く利用されているプロトコル・標準化された通信規格です。コンピュータは TCP/IP スタックと呼ばれるようなソフトウェアを実行することで、定められた規格に則って通信を行います。汎用 OS 環境では、TCP/IP スタックは多くの場合、カーネル空間に OS 機能の一部として実装されています。 課題：通信に関するソフトウェアの研究コミュニティでは、そのようなカーネル空間に実装されている TCP/IP スタックは、近年の高速な NIC の性能を十分に引き出すことが難しいという課題が指摘されてきました。 テクニックの紹介：当記事では、近年の研究コミュニティにおいて比較的一般的な高速化テクニックとされている「カーネルをバイパス（迂回）して TCP 通信を
SEIL/x86 Ayame とミニPCでソフトウェアルータ入門 | IIJ Engineers Blog
今回使用したAnsible のサンプルはこちらです。 NIC周りの設定変更について、特筆すべき事項はないため飛ばします。 注意すべき点として、初期状態からIPアドレスの付け替えが生じるため、NICの構成が完了するためにはSSH先アドレスを変更しながら2度実施する必要があります。 この問題に関しては今後の課題とします。 Ayameのデプロイと設定 この前に事前準備としてAyameのイメージファイルを取得する必要があります。今回はKVM形式を使用します。IIJマルチプロダクトコントローラサービスをご利用の方で試す場合は提供OVAイメージをKVM形式に変換する。またはKVMで構築している部分をVMwareの手順に読み替えてください。 今回は、SEIL公式サイトで配布しているKVM形式のイメージにプロダクトキーをインストールする方法で説明します。 入手したイメージはfiles/var/lib/li
Kubernetesのキャッシュネームサーバとリゾルバ | IIJ Engineers Blog
ただ、サーチリストがこうなっているのは利便性のためだけではなく、もっと切実な理由があります。 サーチリストとndots DNSの一般的な名前解決のルールとして、こんな風に覚えている方もいるかもしれません。 名前にピリオドが含まれていたら、FQDNとみなしてサーチリストを参照せずに名前解決を行う 名前にピリオドが含まれていなければ、サーチリストのドメインを末尾に連結して名前解決する 例えば、こんな具合です。 $ ping myhost # ピリオドが含まれていないため、myhost.example.comが名前解決される PING myhost.example.com (192.168.0.1) 56(84) バイトのデータ 64 バイト応答 送信元 myhost.example.com (192.168.0.1): icmp_seq=1 ttl=57 時間=12.4ミリ秒 $ ping w
urlscan.ioとShodanでお手軽にマルウェアの通信先サーバを調べる | IIJ Engineers Blog
セキュリティ本部データ分析課所属。2020年新卒入社。情報分析基盤のセキュリティログ分析を行う傍ら、マイニングマルウェアやIoTマルウェアを調査しています。 はじめに こんにちは、セキュリティ本部の森下です。 普段は情報分析基盤でセキュリティログの分析を行う傍ら、感染活動の動向を把握するためにマイニングマルウェアやIoTマルウェアを調べたりしています。 一般的にマルウェアに感染すると、C2サーバに通信して攻撃の指令を受けたり、マルウェア配布サーバからさらに別のマルウェアをダウンロードしてきたりします。 セキュリティ製品などによる検知を回避するために、マルウェアの通信先サーバは短期間で変わっていくことが多く、追跡し続けることが必要です。 マルウェアの通信先サーバでは、一般的なサーバとは異なる特徴が表れることがあり、その特徴を把握することで、新しく使われるサーバを迅速に発見できる可能性がありま
マルウェア解析に役立つ、実行ファイルのケーパビリティ検知ツールcapaの入門 | IIJ Engineers Blog
2018年新卒入社し、SOCにてインフラ管理を担当。その後、マルウェア解析や検証業務などに従事。2022年度からは、社内のSREチームにて兼務を開始。主な保持資格は、CISSP, OSCP, GREM, GXPN, RISS, CKA, CKSなど。バイナリを読むのが好きで、一番好きな命令はx86の0x90（NOP命令）。 【IIJ 2022 TECHアドベントカレンダー 12/7（水）の記事です】 はじめに 本記事では、マルウェア解析に活用することができるcapaと呼ばれるツールの概要と使い方を紹介します。日本語での本ツールに関する情報は多くありません。そこで、日本のマルウェア解析者の方に活用していただければと思い、本記事を作成しました。capaという名前を聞いたことはあるが、使ったことはないという方など、今回の記事を通して、実際に触るきっかけとなれば幸いです。 capaとは capaは
パスワードのいらない世界 -あなたのスマホをセキュリティキーに- | IIJ Engineers Blog
はじめに みなさんは普段FIDO2を使ったログインを利用していますか？ FIDO2は、公開鍵暗号方式を利用したセキュアな認証を実現するための標準規格です。ユーザはセキュリティキーと呼ばれるデバイスを利用することで、パスワード等の秘密の情報を覚える負担を軽減してくれます。また、リスト型攻撃やフィッシングの耐性を持っているため、安全で便利な次世代の認証方法として注目されています。 FIDO2の規格は2019年にW3Cで勧告されWeb標準となり、FIDO2を利用できるブラウザやデバイス、またログインできるサービスが増えてきています。私が携わっているクラウド型ID管理サービスであるIIJ IDサービスでも、2020年にFIDO2認証をサポートし、幅広いお客様にご利用頂いてもらっています。 以前も本ブログにて、FIDO2に追加される機能に関するお話( https://eng-blog.iij.ad.
忘れ去られたドメイン名に宿る付喪神 | IIJ Engineers Blog
開発・運用の現場から、IIJのエンジニアが技術的な情報や取り組みについて執筆する公式ブログを運営しています。 こんにちは。IIJ Engineers Blog編集部です。 IIJの社内掲示板では、エンジニアのちょっとした技術ネタが好評となって多くのコメントが付いたり、お役立ち情報が掲載されています。 そんな情報を社内に留めておくのはもったいない！ということで、IIJ Engineers Blog編集部より、選りすぐりの情報をお届けします。 今回は、使わなくなったドメイン名はどのようにすればよいかを紹介します。 そのまま放置しておいてよいのか？（ダメ） 廃止すればよいのか？（もっとダメ） どういった対応を行えばよいのか？ どうぞご覧ください。 終わったサービス・キャンペーンのドメイン名、放置されていませんか？ ドメイン名を放置すると付喪神がやどり、ひとりでにサイトを公開したりメールを出し始め
HTTPS 証明書の Common Name の検証がしれっと禁止されていた件について | IIJ Engineers Blog
開発・運用の現場から、IIJのエンジニアが技術的な情報や取り組みについて執筆する公式ブログを運営しています。 こんにちは。IIJ Engineers Blog編集部です。 IIJの社内掲示板では、エンジニアのちょっとした技術ネタが好評となって多くのコメントが付いたり、お役立ち情報が掲載されています。 今回は、すでにお気づきの方もいるかもしれませんが、いつの間にか HTTPS 証明書の Common Name の検証が禁止 になっていた件について紹介します。 HTTPS 証明書の検証手続きは、RFC2818 で「Subject Alternative Name があればそれで、なければ Common Name を見よ」となっていました。 If a subjectAltName extension of type dNSName is present, that MUST be used as
Teams / Webex 対応！ Linux でバーチャル背景を使う | IIJ Engineers Blog
IIJ ネットワーク本部アプリケーションサービス部・(兼)社長室所属。 メールサービスの運用業務に従事し、日々世界の悪と戦う一児の父親。社内 Power Automate エバンジェリスト(自称)。M3AAWG member / openSUSE Users / WIDE Project メンバー。趣味は大喜利。はがき職人。 【IIJ 2020 TECHアドベントカレンダー 12/2（水）の記事です】 ⇒ 前置きは飛ばして手順を見たい方はこちら 今年を振り返ってみると、在宅勤務を中心とするテレワークが大きく広がった年になりました。 会議は原則リモートになり、企業や組織では、Microsoft Teams、Cisco Webex、Zoom、Google Meet、Slack といったミーティングツールの活用が進んだことでしょう。オンラインミーティングでは、Web カメラを用いたビデオ会議がで
ようこそ、Kubernetes沼へ。商用サービスSREの現場から | IIJ Engineers Blog
社会人生活の半分をフリーランス、半分をIIJで過ごすエンジニア。元々はアプリケーション屋だったはずが、クラウドと出会ったばかりに半身をインフラ屋に売り渡す羽目に。現在はコンテナ技術に傾倒中だが語りだすと長いので割愛。タグをつけるならコンテナ、クラウド、ロードバイク、うどん。 筆者がIIJでパブリッククラウドビジネスを率いていた2010〜2015年頃、今後のITインフラはしばらくIaaSを中心に回っていくのだと考えていたものですが、Docker, Kubernetesという爆弾が投下されました。10年、20年は続くと思われたIaaSの時代がまさか早々に色あせて見えるとは。相変わらずIT業界にも思いもよらないことが突然起こるものです。これだからIT業界はおもしろい。 本連載は、現在IIJでSREを率いている筆者がどのようにしてSREチームを立ち上げ、Kubernetes沼へ飛び込み、悪戦苦闘し
モダンなDNSの構成：IIJ DNSプラットフォームサービスのスゴいところ(第1回) | IIJ Engineers Blog
はじめに 先日、「IIJ DNSプラットフォームサービス」という新たな権威DNSサービスをリリースしました。プレスリリースはこちら。 そしたら、どーまえさんから「新サービスでやってるスゴいことについて記事書いてよ、それも主なものだけかいつまんで紹介するんじゃなくて細かいところまで全部！」とリクエストされました。「え、まじで全部書くんすか？！むっちゃ多いっすよ──。」 IIJのDNSサービスはかなり頑張ってるつもりですが、うちだけじゃなく、同業他社さんや、あるいは自前でDNSサーバを構築運用している企業さんにも頑張ってもらいたいんですよね。営業の立場からすると「ぜんぶIIJに任せてくれや」となるんでしょうけれど、売り文句にマルチプロバイダとあるように、IIJ単独じゃなくて複数のDNS事業者で同じゾーンを持つことで耐障害性を高めよう、ということも今回のサービスのポイントなのです。 IIJのサー
数百のテナントが同居するマルチテナントKubernetesの世界 | IIJ Engineers Blog
Twitterフォロー&条件付きツイートで「バリーくんぬいぐるみ」を抽選で20名にプレゼント！ 応募期間は2019/11/29～2019/12/31まで。詳細はこちらをご覧ください。 今すぐツイートするならこちら→ フォローもお忘れなく！ 【IIJ 2019 TECHアドベントカレンダー 12/6（金）の記事です】 シニアテクニカルマネージャの田口です。今年はKubernetesに始まり、Kubernetesに終わる1年でした。皆さん、コンテナ化の準備は万端ですか？ IIJにおけるKubernetesの活用はまだ黎明期といったところですが、それでも急速に利用が進み、最も巨大なクラスタでは約200名のエンジニアが暮らし、数百のテナント（プロジェクト）が同居する規模にまで育ってきました。そのネタでブログを1本と思ったのですが、1年前に比べるとKubernetesはプロダクション環境での普及が進
IIJ Legs でIoTデバイスをお手軽制御 | IIJ Engineers Blog
IIJ プロダクト本部 応用開発課 所属。2015年に新卒入社。webアプリケーションの実装・運用を中心にやりたいことがあれば何でも手を出してみる所存です。 はじめに プロダクト本部の r-fujimoto です。 今回は7月8日付で公開した IIJ Legs という新しいプロダクトの紹介をしたいと思います。 公式サイト: https://dev.smf.jp/legs/ IIJ Legs はインターネット越しのデバイス制御をお手軽かつパワフルに実現する通信基盤サービスで、自宅のパソコンやRaspberry Piなどにクライアントをインストールして利用することができます。 なにはともあれ下のgifを見てください。これは Legs のWebUIを使ってインターネット越しにRaspberry Piを操作している例です。 軽快にコンソールを操作できているのが分かるでしょうか。SSHなどは使わず、
TLS 1.3の標準化と実装 | IIJ Engineers Blog
IIJ-II 技術研究所 技術開発室の山本です。現在技術開発室は、私を含めた4人で構成されており、主にプログラミング言語Haskellを使って開発を進めています。今回の話題である TLS(Transport Layer Security) 1.3 もHaskellで実装しました。 4年の歳月をかけて議論されてきたTLS 1.3ですが、この8月にめでたく仕様がRFC 8446となりました。貢献者リストに私の名前が載っていることを聞きつけた広報から、ブログ記事の執筆依頼がありましたので、TLS 1.3の標準化や実装の話について書いてみます。 なぜTLS 1.3を標準化する必要があったのか理由を知りたい方は、「TLSの動向」という記事や「TLS 1.3」というスライドを読んで下さい。 インターネットで使われているプロトコルは、IETFという団体で仕様が議論されて策定されます。IETFには、誰でも
IIJ内製運用ツール「iwatch」のご紹介 | IIJ Engineers Blog
操作方法に関して詳しくは、 $ man iwatch をご覧ください。 watch コマンドと比べた時の利点 この iwatch に似た機能をもつコマンドとして有名な watch コマンドがありますが、iwatch には watch コマンドに負けない機能がいくつもあります。 既に上で説明したものもありますが、一覧でまとめると以下のようになります。 コマンド出力のスクロールが可能 出力が縦横に長いコマンドを実行した場合、コンソールのウインドウからはみ出ることが多々ありますが、 tail コマンドや cut コマンドを用いてパイプするなどの工夫をしなくても、iwatch であれば出力をキー操作でスクロールすることが可能です。 出力結果の差分を単語・行・文字単位でハイライト可能 watch コマンドでは -d オプションをつけることにより、文字単位での差分をハイライトすることができますが、 i
Google Public DNS over HTTPS を試す | IIJ Engineers Blog
【2018/11/16 追記】 本記事は、2016 年 4 月に Google Public DNS サーバに実装された、実験的な DNS over HTTPS プロトコルについて紹介しています。DNS over HTTPS プロトコルはその後 IETF の doh ワーキンググループにて標準化が進められ、2年半後の 2018 年 10 月に RFC8484 として出版されました。本記事で紹介したプロトコルは RFC8484 に規定されたプロトコルとはいくつもの点で異なっていることにご注意ください。 Google Inc. が公開 DNS サーバを運営していることはご存知でしょうか? Google Public DNS と呼ばれるこの公開 DNS サーバは、”8.8.8.8″ という特徴的な IP アドレスで全世界のインターネットユーザに対して無料の DNS サーバ(フルレゾルバ)を提供し
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
